À propos des instantanés RDB

Cette page présente les instantanés RDB pour Memorystore pour Redis. Dans cette page, nous partons du principe que vous connaissez les instantanés RDB 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 du cache ou reremplir très facilement le cache à partir d'un stockage persistant. Toutefois, dans certains cas d'utilisation, les temps d'arrêt d'une instance Memorystore ou la perte complète de données d'instance peuvent entraîner de longs temps d'arrêt des applications.

Nous vous recommandons d'utiliser le niveau Standard comme mécanisme principal de 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 susceptibles d'entraîner des vidages de cache. Le niveau Standard fournit une instance disponibilité élevée avec plusieurs instances répliquées et permet une récupération rapide à l'aide du basculement automatique en cas de défaillance de l'instance principale.

Dans certains scénarios, 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 les 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, si nécessaire, une récupération est effectuée à partir du dernier instantané RDB.

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 le comportement suivant:

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

  • Vous choisissez la fréquence et la programmation des instantanés de routine. L'intervalle d'instantanés minimal 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 pour cause d'échec, subit une opération de scaling ou est mise à niveau de la version OSS Redis de votre instance.

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

  • Ce service n'entraîne aucuns frais supplémentaires 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 peut être récupéré. 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 l'instance répliqué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 Redis version 5.0 ou ultérieure.

  • Si votre instance comporte de nombreuses clés (environ 200 millions ou plus), les instantanés et récupérations RDB peuvent être lents. À ce volume de clés, le serveur Redis lui-même peut constituer un 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 de l'instance, vous devez spécifier un intervalle d'instantanés. Vous avez également la possibilité de 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 de leur activation et se poursuivent toutes les heures par la suite.

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 systématiquement respectée si les instantanés réussissent toujours et ne prennent pas plus de temps que l'intervalle de sauvegarde spécifié.

Toutefois, il est préférable de déclencher l'instantané en fonction du planning quotidien. Le calendrier peut s'écarter de celui initialement déterminé pour plusieurs raisons:

  • Si un instantané échoue ou prend plus de temps que l'intervalle spécifié, l'instantané suivant démarre 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 permettre l'exécution de l'instantané.

  • Si un instantané est déjà en cours à un moment aligné sur la programmation quotidienne, il est terminé et l'heure du prochain instantané n'est calculée qu'à partir de l'intervalle entre le début du dernier instantané réussi.

Ajuster la programmation existante

Il se peut que vous souhaitiez suspendre temporairement la prise d'instantanés RDB pendant une certaine période. Cela peut permettre de garantir l'absence d'impact sur les performances lors d'événements critiques ou de désactiver temporairement les instantanés pour résoudre les problèmes de performances.

Pour arrêter temporairement de prendre des instantanés pendant une courte période, vous pouvez définir l'heure de début sur une date ultérieure. Lorsque vous définissez l'heure de début sur une date ultérieure, l'instantané suivant ne commence pas avant cette date. Le dernier instantané est alors 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 redémarrage de l'instance. 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 répliquée en tant que mécanisme de récupération principal au lieu de se 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 répliquée échoue.

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

Lorsqu'ils sont activés, les instantanés RDB s'efforcent au mieux de s'assurer que les sauvegardes sont effectuées à 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 des 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.

Le pire des cas de perte de données pour une récupération à partir d'un instantané correspond à la somme de l'intervalle spécifié depuis le démarrage du dernier instantané réussi et du temps nécessaire à l'enregistrement du prochain instantané dans l'espace de stockage. Dans le cas d'un incident de récupération, utilisez la métrique last_success_age pour afficher le délai de perte de données.

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

Temps de récupération

L'instance n'est pas disponible pendant la restauration 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, vérifiez la métrique RDB recovery remaining time à l'aide de Cloud Monitoring dans la console Google Cloud.

Limiter les récupérations lentes

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 que votre application se reconnecte à 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é ayant échoué est signalé à Cloud Monitoring et l'instantané est relancé immédiatement. Les échecs consécutifs liés aux instantanés 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 en savoir plus sur la détection et la résolution des échecs d'instantanés, consultez la page Surveiller des 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 optimiser les résultats 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 une duplication de processus et un mécanisme "copy-on-write" pour prendre un instantané de l'instance. Selon le modèle des écritures sur 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 correspondre au double de la taille des données de l'instance.

Pour vous assurer que l'instance dispose de suffisamment de mémoire pour réaliser l'instantané, vous devez définir maxmemory-gb sur 80% de la capacité de l'instance, afin que 20% soient réservés à la surcharge. Pour en savoir plus, consultez la section Bonnes pratiques pour la gestion de la mémoire. Cette surcharge de mémoire, en plus des instantanés Monitoring, 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 rapprocher un nombre important 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 à rapprocher de 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 les récupérer à partir d'un instantané non actualisé.

Pour surveiller les instantanés non actualisés, définissez une alerte sur les metrics d'instantané RDB last_status et d'instantané RDB last_success_age.

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 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 diriger le trafic. Une fois l'instance Redis d'origine restaurée, vous pouvez transférer les données restaurées vers la nouvelle instance.

Impact sur les performances des instantanés RDB

Selon 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.

Selon la quantité potentielle de pertes de données 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 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 définir l'intervalle sur 24 heures.

Si votre système présente une charge constante et nécessite des instantanés fréquents, vous devez évaluer soigneusement l'impact sur les performances et évaluer les avantages liés à 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 en cas d'échec. Les instantanés en échec 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 la page Métriques d'instantané RDB. Pour recevoir une notification en cas d'échec d'un instantané, définissez une alerte pour la métrique d'instantané RDB last_status. Vous pouvez également rechercher d'éventuels échecs à l'aide de la console Google Cloud.

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 d'instantané RDB in_progress pour déterminer si un instantané était en cours lorsque des problèmes de performances ont été détectés.

Étapes suivantes