Backup et restauration d'ElastiCache for Redis - Amazon ElastiCache for Redis

Backup et restauration d'ElastiCache for Redis

Les clusters Amazon ElastiCache qui exécutent Redis peuvent sauvegarder leurs données. La sauvegarde peut être utilisée pour restaurer un cluster ou en implanter un nouveau. La sauvegarde se compose des métadonnées du cluster, ainsi que toutes les données figurant dans le cluster. Toutes les sauvegardes sont écrites sur Amazon Simple Storage Service (Amazon S3), qui fournit un stockage durable. A tout moment, vous pouvez restaurer vos données en créant un nouveau cluster Redis et en le remplissant de données provenant d'une sauvegarde. Avec ElastiCache, vous pouvez gérer les sauvegardes à l'aide de la AWS Management Console, la AWS Command Line Interface (AWS CLI) et l'API ElastiCache.

Dans Redis version 2.8.22, la méthode de sauvegarde est sélectionnée en fonction de la mémoire disponible. S'il y a suffisamment de mémoire disponible, un processus enfant est généré et écrit toutes les modifications sur la mémoire réservée du cache pendant que le cache est sauvegardé. Selon le nombre d'écritures sur le cache pendant le processus de sauvegarde, ce processus enfant pourrait consommer toute la mémoire réservée, ce qui ferait échouer la sauvegarde.

Si la mémoire disponible est insuffisante, un processus d'arrière-plan coopératif sans fonction fork est utilisé. La méthode sans fonction fork peut avoir un impact sur la latence et le débit. Pour plus d’informations, consultez Implémentation de la sauvegarde et de la synchronisation.

Pour plus d'informations sur l'impact du processus de sauvegarde sur les performances, consultez Impact sur les performances des sauvegardes.

Cette section présente les processus de sauvegarde et de restauration.

Important

Bien que ce soit rare, le processus de sauvegarde peut ne pas parvenir à créer une sauvegarde, y compris une sauvegarde finale. Les échecs de sauvegarde sont souvent dus à une mémoire réservée insuffisante. Vous devez donc vous assurer de disposer d'une mémoire réservée suffisante avant de lancer une sauvegarde. Si la mémoire dont vous disposez est insuffisante, vous pouvez supprimer des clés ou augmenter la valeur de reserved-memory-percent.

Pour plus d'informations, veuillez consulter les ressources suivantes :

Si vous prévoyez de supprimer un cluster 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, puis vérifiez que son statut est disponible et enfin, supprimez le cluster. En cas d'échec de la sauvegarde, cette étape garantit que les données du cluster seront toujours disponibles. Vous pouvez réessayer de faire une sauvegarde en suivant les bonnes pratiques énoncées précédemment.

Contraintes inhérentes à la sauvegarde

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

  • Pour l'instant, la sauvegarde et la restauration sont prises en charge uniquement pour les clusters exécutés sous Redis.

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

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

  • Sur une période de 24 heures consécutives, vous ne pouvez pas créer plus de 20 sauvegardes manuelles par nœud de cluster.

  • Redis (mode cluster activé) prend uniquement en charge les sauvegardes effectuées au niveau du cluster (pour l'API ou CLI, au niveau du groupe de réplication). Redis (mode cluster activé) ne prend en charge que les sauvegardes effectuées au niveau du cluster (pour l'API ou CLI, au niveau du groupe de réplication).

  • Pendant le processus de sauvegarde, vous ne pouvez effectuer aucune opération d'API ou de la CLI supplémentaire sur le cluster.

  • Si vous utilisez des clusters 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.

Couts inhérents à la sauvegarde

En utilisant ElastiCache, vous pouvez stocker gratuitement une sauvegarde pour chaque cluster Redis actif. L'espace de stockage pour des sauvegardes supplémentaires est facturé au tarif de 0,085 $/Go par mois pour toutes les régions AWS. Il n'y a aucun frais de transfert de données pour la création d'une sauvegarde ou pour la restauration de données à partir d'une sauvegarde dans un cluster Redis.

Impact sur les performances des sauvegardes

Le processus de sauvegarde s'appuie sur la version Redis que vous exécutez. Quant à Redis 2.8.22, le processus n'utilise pas la fonction fork.

Sauvegardes lors de l'exécution de Redis 2.8.22 et versions ultérieures

Les sauvegardes Redis avec les versions 2.8.22 et ultérieures utilisent deux méthodes de sauvegarde. Si la mémoire est insuffisante pour prendre en charge une sauvegarde avec fonction fork, ElastiCache utilise une méthode sans fonction fork avec un traitement coopératif en arrière-plan. S'il y a suffisamment de mémoire pour prendre en charge un processus d'enregistrement avec une fonction fork, le processus utilisé est le même que dans les versions antérieures de Redis.

Si la charge d'écriture est élevée lors d'une sauvegarde sans fonction fork, les écritures sur le cache sont retardées. Ce retard garantit de ne pas accumuler trop de changements et, ainsi, de ne pas empêcher la réussite d'une sauvegarde.

Sauvegardes avec des versions Redis antérieures à la version 2.8.22

Les sauvegardes sont créées à l'aide de l'opération BGSAVE native de Redis. Le processus Redis sur le nœud de cache génère un processus enfant pour écrire toutes les données du cache dans un fichier Redis .rdb. Jusqu'à 10 secondes peuvent être nécessaires pour générer le processus enfant. Pendant ce temps, le processus parent ne peut pas accepter de demandes d'application entrantes. Une fois que le processus enfant s'exécute de façon autonome, le fonctionnement normal du processus parent reprend. Le processus enfant s'interrompt lorsque l'opération de sauvegarde est terminée.

Pendant l'opération d'écriture de la sauvegarde, la mémoire de nœud de cache supplémentaire est utilisée pour de nouvelles écritures. Si cette utilisation de la mémoire supplémentaire dépasse la mémoire disponible du nœud, le traitement peut devenir lent en raison d'une pagination excessive, voire même échouer.

Amélioration des performances de sauvegarde

Vous trouverez ci-après les instructions pour optimiser les performances des sauvegardes.

  • Définissez le paramètre reserved-memory-percent – Pour atténuer une pagination excessive, nous vous conseillons de configurer le paramètre reserved-memory-percent. Ce paramètre empêche Redis de consommer toute la mémoire disponible du nœud et permet de diminuer le volume de pagination. Vous pouvez également observer une optimisation des performances simplement en utilisant un nœud plus grand. Pour plus d'informations sur les paramètres reserved-memory et reserved-memory-percent, consultez Gestion de la mémoire réservée.

     

  • Créez des sauvegardes à partir d'un réplica en lecture – Si vous exécutez Redis dans un groupe de plusieurs nœuds, vous pouvez effectuer une sauvegarde depuis le nœud primaire ou l'un des réplicas 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, ElastiCache effectuera toujours la sauvegarde à partir du nœud primaire. Cela permet de s'assurer de capturer les données Redis les plus récentes, avant que le groupe de réplication soit supprimé.