À propos des instantanés RDB

Cette page présente les instantanés RDB pour Memorystore pour Redis. Cette page suppose que vous connaissez les instantanés RDB Redis Open Source et la fonctionnalité d'importation/exportation de Memorystore.

Pour savoir comment activer, désactiver et surveiller les instantanés RDB, consultez Gérer les instantanés RDB.

Memorystore pour Redis est principalement utilisé comme cache en mémoire. Lorsque vous utilisez Memorystore comme cache, votre application peut tolérer la perte de données de cache ou peut très facilement repopuler le cache à partir d'un magasin persistant. Toutefois, dans certains cas d'utilisation, une indisponibilité d'une instance Memorystore ou une perte complète des données d'instance peuvent entraîner de longues périodes d'indisponibilité des applications.

Nous vous recommandons d'utiliser le niveau Standard comme mécanisme principal pour la haute disponibilité. De plus, l'activation des instantanés RDB sur les instances de niveau standard offre une protection supplémentaire contre les défaillances pouvant entraîner des vidages de cache. Le niveau standard fournit une instance disponibilité élevée avec plusieurs répliques et permet une récupération rapide à l'aide du basculement automatique en cas d'échec de l'instance principale.

Dans certains cas, vous pouvez également vouloir vous assurer que les données peuvent être récupérées à partir de sauvegardes instantanées en cas de défaillance catastrophique des instances de niveau standard. Dans ces scénarios, les sauvegardes automatiques et la possibilité de restaurer des données à partir d'instantanés RDB peuvent offrir une protection supplémentaire contre la perte de données. Si les instantanés RDB sont activés, une récupération est effectuée à partir du dernier instantané RDB, si nécessaire.

Les instantanés RDB conviennent aux cas d'utilisation qui peuvent tolérer une certaine obsolescence des données après la récupération. Vous pouvez également utiliser des instantanés RDB pour automatiser la sauvegarde et la récupération des instances de niveau de base.

Présentation des instantanés RDB

La fonctionnalité d'instantanés RDB présente les caractéristiques suivantes :

  • Stocke des instantanés complets à un moment précis à des intervalles spécifiés par l'utilisateur dans un espace de stockage persistant.

  • Vous choisissez la fréquence et la programmation des instantanés de routine. L'intervalle minimal est de 1h et l'intervalle maximal est de 24h.

  • Les instances de niveau de base récupèrent les données à partir de l'instantané le plus récent chaque fois qu'une instance est redémarrée en raison d'une défaillance, fait l'objet d'une opération de scaling ou d'une mise à niveau de la version OSS de Redis.

  • Par défaut, les instances de niveau standard récupèrent les données à partir de l'instance dupliquée, et non à partir d'un instantané. Toutefois, les instances de niveau standard récupèrent les données à partir d'un instantané si aucune réplique n'est disponible et que le nœud principal et la réplique redémarrent.

  • N'entraîne aucun coût supplémentaire pour la facturation de votre instance.

Comportement supplémentaire

  • Les instantanés sont utilisés pour la récupération d'instances et ne sont pas disponibles pour les restaurations manuelles. À tout moment, seul le dernier instantané réussi est disponible pour la récupération. En plus des instantanés RDB, vous pouvez utiliser Exporter et importer pour sauvegarder et restaurer manuellement vos données.

  • Sur une instance de niveau standard, le snapshot est pris sur le réplica pour minimiser l'utilisation de la mémoire et du processeur sur le nœud principal. Les instantanés ne sont jamais pris à partir du nœud principal.

Contraintes

  • Disponible sur les instances Memorystore pour Redis utilisant Redis 5.0 ou version ultérieure.

  • Si votre instance comporte de nombreuses clés (environ 200 millions ou plus), les instantanés et les récupérations RDB peuvent être lents. À ce volume de clés, le serveur Redis lui-même peut être le goulot d'étranglement qui ralentit les instantanés et les récupérations.

Programmer des instantanés RDB

Lorsque vous activez les instantanés RDB lors de la création d'une instance, vous devez spécifier un intervalle d'instantanés. Vous pouvez également spécifier une heure de début. Ensemble, ils définissent la programmation quotidienne des instantanés. Les intervalles que vous pouvez définir sont 1h, 6h, 12h et 24h. Par exemple, si vous définissez l'heure de début sur 4h et l'intervalle sur 1 heure, les instantanés commencent à 4h le jour où ils sont activés, puis se poursuivent toutes les heures.

Si aucune heure de début n'est spécifiée, le premier instantané est pris dès que possible, et l'intervalle est respecté. Par exemple, si vous ne spécifiez pas d'heure de début et que vous définissez un intervalle d'une heure, l'instantané peut commencer à 6h13, puis se poursuivre à 7h13, 8h13, etc.

Si une heure de début est spécifiée, la programmation quotidienne est toujours respectée si les instantanés réussissent toujours et ne prennent pas plus de temps que l'intervalle de sauvegarde spécifié.

Toutefois, le déclenchement de l'instantané en fonction de la programmation quotidienne est effectué au mieux. La programmation peut s'écarter de celle initialement déterminée pour plusieurs raisons :

  • Si un instantané échoue ou prend plus de temps que l'intervalle d'instantané spécifié, l'instantané suivant commence immédiatement après la fin de l'instantané en cours.

    • Pour éviter que l'instantané ne s'exécute en continu et ne surcharge l'instance, il est recommandé de définir un intervalle suffisamment long pour que l'instantané puisse se terminer.

  • Si un instantané est déjà en cours à une heure correspondant à la programmation quotidienne, il se termine et l'heure du prochain instantané est calculée uniquement en fonction de l'intervalle depuis le début du dernier instantané réussi.

Ajuster une programmation existante

Vous pouvez être amené à mettre en pause temporairement la création d'instantanés RDB pendant une certaine période. Cela peut être pour s'assurer qu'il n'y a pas d'impact sur les performances lors d'événements critiques ou pour désactiver temporairement les instantanés afin de résoudre les problèmes de performances.

Pour arrêter temporairement la prise d'instantanés pendant une courte période, vous pouvez définir une date de début ultérieure. Une fois que vous avez défini une date de début ultérieure, le prochain instantané ne démarre qu'à cette date. Dans ce cas, le dernier instantané est conservé pendant au moins sept jours et est utilisé en cas de récupération.

Pour en savoir plus sur l'ajustement des programmations d'instantanés, consultez Ajuster une programmation d'instantanés.

Comportement de récupération

Les instances Redis de niveau de base déclenchent une récupération chaque fois qu'elles sont redémarrées. Les opérations courantes qui déclenchent des redémarrages sont la mise à l'échelle et la mise à niveau de la version de votre instance. Les instantanés RDB préservent les données des instances de niveau de base lors de ces opérations qui entraînent des redémarrages, une maintenance planifiée et des défaillances système imprévues.

Les instances Redis de niveau standard basculent vers une instance répliquée comme mécanisme de récupération principal au lieu de charger à partir d'un instantané. Une instance de niveau standard est récupérée à partir de l'instantané lorsque la restauration à partir d'une réplique échoue.

Cohérence des données lors de la récupération

Lorsqu'ils sont activés, les instantanés RDB font de leur mieux pour que les sauvegardes aient lieu à l'intervalle spécifié, mais cela ne peut pas être garanti. Les instantanés peuvent échouer pour plusieurs raisons. Consultez les bonnes pratiques pour savoir comment configurer et surveiller les instances lorsque les instantanés RDB sont activés.

Si le snapshot échoue consécutivement à plusieurs intervalles, la dernière sauvegarde disponible peut être arbitrairement obsolète.

Dans le pire des cas, la perte de données lors d'une récupération à partir d'un instantané correspond à la somme de l'intervalle spécifié depuis le début du dernier instantané valide et du temps nécessaire pour enregistrer le prochain instantané dans le stockage. En cas d'incident de récupération, utilisez la métrique last_success_age pour afficher la période de perte de données.

Nous vous recommandons de configurer des alertes pour détecter les échecs des instantanés planifiés et prendre les mesures correctives nécessaires. Pour en savoir plus sur la configuration des alertes, consultez Surveiller les instantanés.

Temps de récupération

L'instance est indisponible pendant qu'elle récupère à partir d'un instantané. Le temps de récupération dépend de la taille de l'instantané. Pour comprendre le temps de récupération prévu, consultez la métrique RDB recovery remaining time à l'aide de Cloud Monitoring dans la console Google Cloud .

Atténuer la lenteur de la récupération

La récupération à partir d'un instantané peut parfois prendre plus de temps que prévu. Vous devrez peut-être prendre des mesures pour reconnecter votre application à Redis le plus rapidement possible.

Dans ce cas, vous pouvez créer une instance Redis et y rediriger le trafic des applications. Vous pourrez ensuite transférer les données restaurées vers la nouvelle instance une fois que l'instance d'origine aura été récupérée.

Échec de la création d'instantané et échec de la récupération

Échec de l'instantané

Tout instantané ayant échoué est signalé à Cloud Monitoring, et une nouvelle tentative est effectuée immédiatement. Les échecs d'instantanés consécutifs augmentent la quantité de données perdues en cas de récupération, car les données récupérées deviennent de plus en plus obsolètes. Pour savoir comment détecter et résoudre les échecs d'instantanés, consultez Surveiller les instantanés.

Échec de la récupération

Les échecs de récupération sont rares, mais peuvent se produire. En cas d'échec de la récupération, l'instance est récupérée sans données.

Bonnes pratiques

Pour obtenir les meilleurs résultats lors de la sauvegarde de votre instance avec des instantanés RDB, vous devez suivre les bonnes pratiques décrites ci-dessous :

Gestion de la mémoire

Les instantanés RDB utilisent un fork de processus et un mécanisme de copie sur écriture pour prendre un instantané de l'instance. En fonction du modèle d'écriture dans l'instance, la mémoire utilisée de l'instance augmente à mesure que les pages concernées par les écritures sont copiées. Dans le pire des cas, l'empreinte mémoire peut être deux fois plus importante que la taille des données dans l'instance.

Pour vous assurer que l'instance dispose de suffisamment de mémoire pour effectuer l'instantané, vous devez définir maxmemory-gb sur 80 % de la capacité de l'instance afin que 20 % soient réservés aux frais généraux. Pour en savoir plus, consultez les bonnes pratiques pour la gestion de la mémoire. Cette surcharge de mémoire, en plus des instantanés de surveillance, vous aide à gérer votre charge de travail pour que les instantanés soient réussis.

Instantanés obsolètes

La récupération de votre instance à partir d'un ancien instantané peut entraîner des problèmes de performances pour votre application, car elle tente de réconcilier une quantité importante de clés obsolètes ou d'autres modifications apportées à votre base de données, comme un changement de schéma.

Si vous pensez que votre instantané est trop ancien ou que votre instance a subi d'autres modifications importantes difficiles à concilier avec l'instantané, vous pouvez désactiver puis réactiver les instantanés RDB. Cette opération supprime les instantanés existants, ce qui vous permet d'éviter de récupérer des données à partir d'un instantané obsolète.

Pour surveiller les instantanés obsolètes, définissez une alerte sur les métriques last_status et last_success_age des instantanés RDB.

Récupération prolongée à partir d'un instantané

Nous vous recommandons de configurer une alerte pour la métrique redis.googleapis.com/server/uptime afin d'être averti si votre instance devient indisponible.

Si votre instance est indisponible et que la récupération à partir d'un instantané prend trop de temps, vous pouvez créer une instance Redis et y rediriger le trafic. Une fois l'instance Redis d'origine rétablie, vous pouvez transférer les données restaurées vers la nouvelle instance.

Impact des instantanés RDB sur les performances

En fonction de votre modèle de charge de travail, les snapshots RDB peuvent avoir un impact sur les performances de l'instance et augmenter la latence de vos applications.

En fonction de la quantité de données potentiellement perdues que votre application peut tolérer, vous pouvez minimiser l'impact des instantanés RDB sur les performances en les programmant pour qu'ils s'exécutent pendant les périodes de faible trafic d'instance.

Utilisez l'heure de début et l'intervalle pour programmer les instantanés aux heures requises. Par exemple, si votre charge est très faible de 1h à 4h du matin, vous pouvez définir l'heure de début sur 3h et l'intervalle sur 24 heures.

Si votre système a une charge constante et nécessite des instantanés fréquents, vous devez évaluer attentivement l'impact sur les performances et peser les avantages de l'utilisation d'instantanés RDB pour la charge de travail.

Surveillance des instantanés

Il est important de surveiller les instantanés et de configurer des alertes en cas d'échec. Les instantanés ayant échoué peuvent indiquer une instance surchargée qui peut continuer à avoir du mal à récupérer à partir de l'instantané.

Pour obtenir la liste des métriques disponibles pour la surveillance des instantanés, consultez Métriques des instantanés RDB. Pour recevoir une notification en cas d'échec d'un instantané, définissez une alerte pour la métrique last_status d'instantané RDB. Vous pouvez également utiliser la console Google Cloud pour vérifier si des échecs se sont produits.

Surveiller l'impact sur les performances

Vous pouvez surveiller l'impact des instantanés sur les performances de votre instance Memorystore en consultant les métriques disponibles dans Cloud Monitoring, comme l'utilisation du processeur, de la mémoire, etc. Si vous constatez une baisse des performances, vous pouvez utiliser la métrique in_progress des instantanés RDB pour déterminer si un instantané était en cours lorsque des problèmes de performances ont été détectés.

Étapes suivantes