Haute disponibilité pour Memorystore pour Redis

Cette page décrit la haute disponibilité (HA) pour les instances Memorystore pour Redis au niveau standard.

Le niveau standard protège une instance Redis contre les défaillances courantes en répliquant les données sur une ou plusieurs répliques et en fournissant un basculement rapide et automatique vers une réplique.

Une instance de niveau standard dont le paramètre readReplicaMode est désactivé contient une instance principale et un réplica qui fournit une fonctionnalité de haute disponibilité. Une instance de niveau standard pour laquelle ce paramètre est activé comporte une instance principale et une à cinq instances répliquées avec accès en lecture. Dans cette configuration, les instances dupliquées avec accès en lecture effectuent des lectures et fournissent une assistance en cas de basculement pour la fonctionnalité de haute disponibilité. Pour savoir si le paramètre readReplicaMode est désactivé ou activé, consultez Afficher les informations sur les instances répliquées avec accès en lecture pour votre instance.

Memorystore pour Redis offre une haute disponibilité en répliquant une instance principale sur une ou plusieurs répliques. Memorystore pour Redis utilise le protocole de réplication asynchrone pour copier sur les répliques les modifications que vous apportez aux données de l'instance principale. En raison de la nature asynchrone de la réplication et en fonction du taux d'écriture de l'instance principale, les instances répliquées peuvent accuser un retard par rapport à l'instance.

Si l'instance principale échoue, l'instance bascule automatiquement vers une réplique. Pour les instances comportant plusieurs instances répliquées, l'instance bascule automatiquement vers une instance répliquée opérationnelle présentant le délai de réplication le plus faible.

Si vous configurez une instance pour qu'elle ne comporte qu'une seule réplique sans accès en lecture, Memorystore pour Redis redirige toutes les connexions d'application vers le point de terminaison principal. Si vous configurez l'instance pour qu'elle utilise des instances répliquées avec accès en lecture, les applications peuvent également utiliser le point de terminaison de lecture pour répartir les requêtes de lecture sur toutes les répliques.

Persistance des données et haute disponibilité

Bien que le niveau standard offre une haute disponibilité (HA) grâce à la réplication et au basculement automatique, la haute disponibilité ne garantit pas une durabilité totale des données. Memorystore pour Redis ne peut pas garantir la durabilité complète des données, même si la haute disponibilité est activée, lors de certains événements catastrophiques, tels que des défaillances régionales temporaires.

Pour protéger vos données et fournir un niveau de persistance de base, les instantanés RDB sont activés par défaut lorsque vous créez une instance Memorystore pour Redis à l'aide de la console Google Cloud .

Pour les charges de travail de production, tenez compte des bonnes pratiques suivantes afin d'améliorer encore la résilience de vos données :

  • Reprise après sinistre : Memorystore pour Redis n'est pas compatible avec la réplication interrégionale. Si votre stratégie de reprise après sinistre nécessite une réplication multirégionale pour une véritable résilience régionale, nous vous recommandons d'utiliser une instance Memorystore for Valkey. Pour en savoir plus sur la configuration et la gestion des instances secondaires dans les régions, consultez Utiliser la réplication interrégionale dans la documentation Memorystore pour Valkey.
  • Durabilité maximale : si votre application nécessite le plus haut niveau de durabilité possible pour les données, nous vous recommandons d'utiliser une instance Memorystore pour Valkey configurée avec la réplication birégionale, les sauvegardes quotidiennes automatiques et la persistance AOF (Append-Only File). Cette combinaison offre la protection la plus efficace contre la perte de données. Pour en savoir plus, consultez Présentation de la persistance dans la documentation Memorystore pour Valkey.

Lorsqu'un basculement se produit

Un basculement se produit lorsque l'instance principale échoue. Lors d'un basculement, l'instance principale et le point de terminaison de lecture sont automatiquement redirigés vers la nouvelle instance principale et les répliques. Memorystore pour Redis abandonne toutes les connexions au point de terminaison principal. Memorystore pour Redis supprime également les connexions au point de terminaison en lecture de l'instance répliquée en lecture promue.

Impact d'un basculement sur votre application

Lorsque l'instance principale bascule sur l'instance répliquée, Memorystore pour Redis abandonne les connexions existantes au point de terminaison principal de l'instance. L'instance n'est pas disponible pendant 30 secondes en moyenne lors des réparations automatiques et pendant 15 secondes lors des événements de maintenance. Une fois la connexion rétablie, votre application est automatiquement redirigée vers la nouvelle instance principale à l'aide de la même chaîne de connexion ou adresse IP. Vous n'avez pas besoin de mettre à jour votre application après un basculement.

Lors d'un basculement, s'il existe des connexions au point de terminaison de lecture, Memorystore pour Redis supprime les connexions à la réplique qui est promue en instance principale. Memorystore pour Redis continue de traiter les connexions aux autres répliques. Une fois le basculement terminé et la nouvelle réplique disponible, Memorystore pour Redis redirige les connexions vers la nouvelle réplique.

Réessayer la connexion à l'instance après un basculement

Lors d'un basculement, Memorystore pour Redis abandonne toutes les connexions à partir du point de terminaison principal. En fonction du nombre de réplicas, Memorystore pour Redis peut également supprimer certaines connexions en lecture.

En raison de cette perte de connexion, votre application doit réessayer de rétablir la connexion. Nous vous recommandons d'utiliser un intervalle exponentiel entre les tentatives pour la logique de nouvelle tentative afin de vous assurer de ne pas surcharger votre instance avec trop de requêtes de nouvelle tentative. En plus d'inclure une logique de nouvelle tentative, nous vous recommandons de tester l'impact d'un basculement sur votre application en effectuant un basculement manuel.

La plupart des clients Redis disposent de fonctionnalités de réessai intégrées. Si une perte de connexion se produit en raison d'un basculement, nous vous recommandons d'utiliser ces fonctionnalités de réessai.

Un basculement se produit lorsque vous effectuez les tâches suivantes :

Si vous implémentez une logique de réessai dans votre application pour gérer les pertes de connexion en raison des basculements, votre instance ne devrait pas subir d'impact significatif sur les performances.

Afficher l'état de la haute disponibilité

Vous pouvez consulter les métriques de haute disponibilité de votre instance Redis à l'aide de Cloud Monitoring. Pour en savoir plus sur les métriques fournies par Cloud Monitoring pour Memorystore pour Redis, consultez Surveiller les instances Redis et Métriques de surveillance compatibles pour Memorystore pour Redis.

Pour afficher l'état de la réplication intégrée fournie par Redis, utilisez la commande INFO.