À propos des instantanés RDB

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

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 remplir à nouveau le cache à partir d'un magasin persistant. Toutefois, dans certains cas d'utilisation, les temps d'arrêt d'une instance Memorystore ou la 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é. 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 instances dupliquées et permet une récupération rapide à l'aide du basculement automatique en cas de défaillance de l'instance principale.

Dans certains cas, vous pouvez également vous assurer que les données peuvent être récupérées à partir de sauvegardes d'instantanés en cas de défaillance catastrophique des instances de niveau standard. Dans ces scénarios, les sauvegardes automatisées 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. Lorsque 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 le comportement suivant :

  • Stocke des instantanés complets à un moment donné à des intervalles spécifiés par l'utilisateur sur un 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 le maximal 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 fait l'objet d'une opération de scaling, ou qu'elle est mise à niveau pour la version OSS Redis de votre instance.

  • Par défaut, les instances de niveau standard récupèrent les données à partir de l'instance dupliquée, et non d'un instantané. Toutefois, les instances de niveau standard récupèrent les données à partir d'un instantané si une instance dupliquée n'est pas disponible et que l'instance principale et l'instance dupliquée sont redémarrées.

  • 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'instance 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 l'exportation et l'importation pour sauvegarder et restaurer manuellement vos données.

  • Sur une instance de niveau standard, l'instantané est pris sur l'instance dupliquée afin de 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 de Redis ou une 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.

Planifier 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 entre les instantanés. Vous avez également la possibilité de spécifier une heure de début. Ensemble, ces éléments 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 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, avec une heure de début non spécifiée et 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é au mieux. La programmation peut s'écarter de la programmation 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é actuel.

    • 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, cet instantané se termine et l'heure de l'instantané suivant est calculée uniquement en fonction de l'intervalle à partir du début du dernier instantané réussi.

Ajuster la programmation existante

Vous pouvez rencontrer des scénarios dans lesquels vous souhaitez suspendre temporairement la prise d'instantanés RDB pendant une certaine période. Cela peut être nécessaire 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 ajuster l'heure de début à une date ultérieure. Une fois que vous avez ajusté l'heure de début à une date ultérieure, l'instantané suivant ne démarre pas avant cette date. Si vous effectuez cette opération, 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 des instantanés.

Comportement de récupération

Les instances Redis de niveau de base déclenchent une récupération chaque fois que l'instance est redémarrée. Les opérations courantes qui déclenchent des redémarrages sont le scaling et la mise à niveau de la version de votre instance. Les instantanés RDB conservent les données d'instance 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 dupliquée comme mécanisme de récupération principal plutôt que 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 instance dupliquée é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 s'assurer que les sauvegardes ont 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 configurer et surveiller les instances lorsque les instantanés RDB sont activés.

Si l'instantané échoue consécutivement sur plusieurs intervalles, la dernière sauvegarde disponible peut être arbitrairement obsolète.

Dans le pire des cas, la perte de données pour une récupération à partir d'un instantané correspond à la somme de l'intervalle spécifié depuis le dernier bon instantané et du temps nécessaire pour enregistrer l'instantané suivant 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 définir des alertes pour détecter l'échec 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 sa 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 RDB recovery remaining time métrique à l'aide de Cloud Monitoring dans la Google Cloud console.

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

Parfois, la récupération à partir d'un instantané peut 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 diriger le trafic de l'application. Vous pouvez ensuite transférer les données restaurées vers la nouvelle instance une fois que l'instance d'origine est récupérée.

Échec d'instantané et échec de récupération

Échec d'instantané

Tout instantané ayant échoué est signalé à Cloud Monitoring, et l'instantané est immédiatement retenté. 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 récupération

Les échecs de récupération sont rares, mais peuvent se produire. En cas d'échec de 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, suivez 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 à l'écriture" pour prendre un instantané de l'instance. En fonction du modèle d'écritures dans l' instance, la mémoire utilisée de l'instance augmente à mesure que les pages touché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 terminer 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 de la surveillance des instantanés Monitoring snapshots , 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 instantané obsolète 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, telles qu'une modification de schéma.

Si vous pensez que votre instantané est trop obsolète ou que votre instance a subi d'autres modifications importantes difficiles à réconcilier avec l'instantané, vous pouvez désactiver, puis réactiver les instantanés RDB. Cela supprime les instantanés existants, ce qui vous permet d'éviter de récupérer à 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 définir une alerte pour la redis.googleapis.com/server/uptime métrique afin de vous avertir 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 diriger le trafic. Une fois que l' instance Redis d'origine est récupérée, vous pouvez transférer les données restaurées vers la nouvelle instance.

Impact des instantanés RDB sur les performances

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

En fonction de 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 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 entre 1h et 4h, 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 soigneusement l'impact sur les performances et comparer 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 définir des alertes pour les instantanés ayant échoué. Les instantanés ayant échoué peuvent indiquer une instance surchargée qui peut continuer à avoir des difficultés à 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 être averti d'un instantané ayant échoué, définissez une alerte pour la métrique last_status des instantanés RDB. Vous pouvez également utiliser la Google Cloud console pour vérifier les échecs.

Surveiller l'impact sur les performances

Vous pouvez surveiller l'impact d'un instantané sur les performances de votre instance Memorystore en affichant les métriques disponibles via Cloud Monitoring telles que l'utilisation du processeur, l'utilisation 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.

Étape suivante