À 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 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 stockage persistant. Toutefois, dans certains cas d'utilisation, un temps d'arrêt d'une instance Memorystore ou une perte complète des données d'instance peuvent entraîner de longs temps d'arrêt de l'application.

Nous vous recommandons d'utiliser le niveau Standard comme mécanisme principal pour la haute disponibilité (HA). 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. De plus, l'activation des instantanés RDB sur les instances de niveau standard offre une protection supplémentaire contre les défaillances de nœuds.

Dans certains cas, vous pouvez également souhaiter vous assurer de pouvoir récupérer des données à partir de sauvegardes d'instantanés. Dans ces scénarios, les sauvegardes 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 vous activez les instantanés RDB et que vous devez récupérer vos données, Memorystore pour Redis peut le faire à partir du dernier instantané. Ces instantanés sont réservés à la récupération interne du système et vous ne pouvez pas y accéder. Vous pouvez également utiliser les instantanés 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 le comportement suivant :

  • 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 entre les instantanés 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, qu'elle subit une opération de scaling ou qu'elle subit une mise à niveau de version.

  • Par défaut, les instances de niveau standard récupèrent les données à partir de la réplique, et non 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 si le nœud principal et la réplique sont redémarrés.

  • 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 l'instance principale. Les instantanés ne sont jamais pris à partir du nœud principal.

Contraintes

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

  • 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é. 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 et 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é de la manière la plus optimale possible. Le calendrier peut s'écarter du calendrier initialement déterminé pour plusieurs raisons :

  • Si un instantané échoue ou met plus de temps que l'intervalle d'instantané spécifié pour se terminer, 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é se termine.
  • 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é à suspendre 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 ajusté l'heure de début à une date 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 la 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, des opérations de maintenance planifiées 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 l'instantané é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é correct 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 des actions correctives. Pour en savoir plus sur la configuration des alertes, consultez Surveiller les instantanés.

Temps de récupération

L'instance n'est pas disponible pendant qu'elle est en cours de récupération à 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 de l'application. 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 l'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 problèmes 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 aucune donnée.

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'espace mémoire utilisé peut être le double de 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 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 obtenir des instantanés 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 d'anciennes clés 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 n'est pas disponible 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.

Selon la quantité de perte de données potentielle que votre application peut tolérer, vous pouvez minimiser l'impact des instantanés RDB sur les performances en planifiant leur exécution 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 du matin 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.

Surveiller les 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 à se rétablir à 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