Instantané et restauration

ElastiCache Les caches Amazon exécutant Redis OSS peuvent sauvegarder leurs données en créant un instantané. Vous pouvez utiliser la sauvegarde pour restaurer un cache ou des données de départ dans un nouveau cache. La sauvegarde se compose des métadonnées du cache et de toutes les données figurant dans le cache. Toutes les sauvegardes sont écrites sur Amazon Simple Storage Service (Amazon S3), qui fournit un stockage durable. À tout moment, vous pouvez restaurer vos données en créant un nouveau cache et en le remplissant avec les données d'une sauvegarde. Avec ElastiCache, vous pouvez gérer les sauvegardes à l'aide de AWS Management Console, the AWS Command Line Interface (AWS CLI) et de l' ElastiCache API.

Si vous prévoyez de supprimer un cache et qu’il est important de préserver les données, vous pouvez prendre une précaution supplémentaire. Pour ce faire, créez une sauvegarde manuelle, vérifiez que son statut est disponible, puis supprimez le cache. En cas d’échec de la sauvegarde, cette étape garantit que les données du cache seront toujours disponibles. Vous pouvez réessayer de faire une sauvegarde en suivant les bonnes pratiques énoncées précédemment.

Rubriques

• Contraintes inhérentes à la sauvegarde
• Impact sur les performances des sauvegardes de clusters auto-conçus
• Planification des sauvegardes automatiques
• Réalisation de sauvegardes manuelles
• Création d'une sauvegarde finale
• Description des sauvegardes
• Copie de sauvegardes
• Exportation d'une sauvegarde
• Restauration à partir d’une sauvegarde dans un nouveau cache
• Suppression d'une sauvegarde
• Étiquetage des sauvegardes
• Alimentation d’un nouveau cluster auto-conçu avec une sauvegarde créée en externe

Contraintes inhérentes à la sauvegarde

Les contraintes suivantes doivent être prises en compte lorsque vous planifiez ou procédez à des procédures de sauvegarde :

• La sauvegarde et la restauration ne sont prises en charge que pour les caches exécutés sur Redis OSS ou Serverless Memcached.

• Pour les clusters Redis OSS (mode cluster désactivé), la sauvegarde et la restauration ne sont pas prises en charge sur les cache.t1.micro nœuds. Tous les autres types de nœuds de cache sont pris en charge.

• Pour les clusters Redis OSS (mode cluster activé), la sauvegarde et la restauration sont prises en charge pour tous les types de nœuds.

• Au cours d'une période continue de 24 heures, vous ne pouvez pas créer plus de 24 sauvegardes manuelles par cache sans serveur. Pour les clusters conçus par Redis OSS, vous ne pouvez pas créer plus de 20 sauvegardes manuelles par nœud du cluster.

• Redis OSS (mode cluster activé) prend uniquement en charge les sauvegardes au niveau du cluster (pour l'API ou la CLI, au niveau du groupe de réplication). Redis OSS (mode cluster activé) ne prend pas en charge les sauvegardes au niveau de la partition (pour l'API ou la CLI, au niveau du groupe de nœuds).

• Pendant le processus de sauvegarde, vous ne pouvez exécuter aucune autre opération d'API ou de CLI sur le cache sans serveur. Vous pouvez exécuter des opérations d'API ou de CLI sur un cluster conçu par vos soins pendant la sauvegarde.

• Si vous utilisez des caches avec hiérarchisation des données, vous ne pouvez pas exporter de sauvegarde vers Amazon S3.

• Vous pouvez restaurer une sauvegarde d’un cluster à l’aide du type de nœud r6gd uniquement sur des clusters utilisant le type de nœud r6gd.

Impact sur les performances des sauvegardes de clusters auto-conçus

Les sauvegardes sur les caches sans serveur sont transparentes pour l’application et n’ont aucun impact sur les performances. Cependant, lors de la création de sauvegardes pour des clusters auto-conçus, il peut y avoir un certain impact sur les performances en fonction de la mémoire réservée disponible. Les clusters conçus par vos soins ne sont pas disponibles avec ElastiCache Memcached, mais ils le sont avec ElastiCache Redis OSS.

Vous trouverez ci-après des instructions pour optimiser les performances des sauvegardes pour les clusters auto-conçus.

• Définir le reserved-memory-percent paramètre : pour limiter le pagination excessive, nous vous recommandons de définir le reserved-memory-percentparamètre. Ce paramètre empêche Redis OSS de consommer toute la mémoire disponible du nœud et peut contribuer à réduire la quantité de pagination. Vous pouvez également observer une optimisation des performances simplement en utilisant un nœud plus grand. Pour plus d'informations sur la mémoire réservée et les reserved-memory-percentparamètres, consultez. Gestion de la mémoire réservée

   

• Création de sauvegardes à partir d'une réplique en lecture — Si vous exécutez Redis OSS dans un groupe de nœuds comportant plusieurs nœuds, vous pouvez effectuer une sauvegarde à partir du nœud principal ou de l'une des répliques en lecture. En raison des ressources système nécessaires au cours d'un BGSAVE, nous vous conseillons de créer des sauvegardes à partir de l'un des réplicas en lecture. Pendant la création de la sauvegarde à partir du réplica, le nœud principal n'est pas concerné par les exigences de ressources BGSAVE. Le nœud principal peut continuer à répondre aux demandes sans ralentir.

  Pour ce faire, veuillez consulter Création d'une sauvegarde manuelle (console) et dans le Cluster Name (Nom du cluster) dans la fenêtre Create Backup (Créer une Backup), choisissez un réplica au lieu du nœud primaire par défaut.

Si vous supprimez un groupe de réplication et demandez une sauvegarde finale, la sauvegarde est ElastiCache toujours prise depuis le nœud principal. Cela garantit que vous capturez les toutes dernières données Redis OSS, avant que le groupe de réplication ne soit supprimé.