À 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 très facilement le réalimenter à partir d'un magasin persistant. Toutefois, dans certains cas d'utilisation, un temps d'arrêt d'une instance Memorystore ou une perte complète de 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 de haute disponibilité. En outre, 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 offre une instance disponibilité élevée avec plusieurs réplications 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 automatiques et la possibilité de restaurer des données à partir d'instantanés de 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 pouvant 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 des instantanés est 1h et le maximum est 24h.

  • Les instances de niveau de base récupèrent les données 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 est mise à niveau vers 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 à partir d'un instantané. Toutefois, les instances de niveau standard récupèrent les données à partir d'un instantané si un réplica n'est pas disponible et que l'instance principale et le réplica sont redémarrés.

  • N'entraîne aucun coût supplémentaire sur la facturation de vos instances.

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, l'instantané est pris sur le réplica pour minimiser l'utilisation de la mémoire et du processeur sur le principal. Les instantanés ne sont jamais créés à 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 et se poursuivent toutes les heures par la suite.

Si aucune heure de début n'est spécifiée, le premier instantané est créé 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 planification 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 planification quotidienne est effectué au mieux. Le calendrier peut différer de celui initialement déterminé 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, nous vous recommandons de définir un intervalle suffisamment long pour que l'instantané soit terminé.

  • Si un instantané est déjà en cours à une heure alignée sur la planification quotidienne, cet instantané se termine et l'heure de l'instantané suivant est calculée uniquement sur l'intervalle entre le début du dernier instantané réussi et l'heure actuelle.

Ajuster un planning existant

Vous pouvez être amené à suspendre temporairement la création d'instantanés RDB pendant une certaine période. Cela peut être fait 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 l'heure de début sur une date ultérieure, l'instantané suivant ne commence 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 le scaling 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 provoquent des redémarrages, une maintenance planifiée et des défaillances système imprévues.

Les instances Redis de niveau standard basculent vers un réplica 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'un réplicat é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 sont effectuées à l'intervalle spécifié, mais cela n'est pas garanti. Les instantanés peuvent échouer pour différentes 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 sur plusieurs intervalles, la dernière sauvegarde disponible peut être arbitrairement obsolète.

La perte de données la plus grave pour 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 l'espace de 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 les échecs des instantanés planifiés et prendre les mesures correctives nécessaires. Pour en savoir plus sur la configuration d'alertes, consultez la section Surveiller les instantanés.

Temps de récupération

L'instance est indisponible pendant la récupération à partir d'un instantané. La durée de récupération dépend de la taille de l'instantané. Pour comprendre le temps de récupération prévu, vérifiez 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 diriger le trafic de l'application. Vous pouvez ensuite transférer les données restaurées vers la nouvelle instance une fois l'instance d'origine récupérée.

Échec de l'instantané et de la récupération

Échec de l'instantané

Tout instantané qui échoue est signalé à Cloud Monitoring, et une nouvelle tentative est immédiatement effectuée. 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 la section Surveiller les instantanés.

Échec de la récupération

Les échecs de récupération sont rares, mais peuvent se produire. En cas de défaillance 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 à l'aide d'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 créer un instantané de l'instance. En fonction du schéma d'écritures 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 peut doubler 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 de la surveillance des instantanés, 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 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'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 à 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 de l'instantané RDB.

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

Nous vous recommandons de définir une alerte pour la métrique redis.googleapis.com/server/uptime afin de vous avertir si votre instance devient indisponible.

Si votre instance n'est pas disponible et qu'une 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é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 de votre modèle de 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 données perdues que votre application peut tolérer, vous pouvez minimiser l'impact sur les performances des instantanés de RDB 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 planifier les instantanés aux heures requises. Par exemple, si votre charge est très faible de 1h à 4h, vous pouvez définir l'heure de début sur 3h et l'intervalle sur 24 heures.

Si votre système est soumis à 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 qui échouent 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 la page Métriques des instantanés de RDB. Pour recevoir une notification d'échec d'un instantané, définissez une alerte pour la métrique last_status de l'instantané RDB. Vous pouvez également utiliser la console Google Cloud pour rechercher d'éventuels échecs.

Surveiller l'impact sur les performances

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

Étape suivante