Cette page décrit la haute disponibilité pour les instances Memorystore pour Redis au niveau standard.
Aperçu
Le niveau standard protège les instances Redis des défaillances courantes en répliquant les données vers une ou plusieurs instances dupliquées et en offrant un basculement automatique rapide vers une instance dupliquée.
Le niveau standard est provisionné avec un nœud principal et un ou plusieurs nœuds d'instances dupliquées. Une instance de niveau standard pour laquelle le mode readReplicaMode est désactivé possède une seule instance dupliquée non lue. Une instance de niveau standard pour laquelle le mode readReplicaMode est activé possède une à cinq instances dupliquées avec accès en lecture. Pour déterminer si le mode readReplicaMode est activé, consultez la section Afficher les informations sur l'instance dupliquée avec accès en lecture.
Memorystore pour Redis fournit la haute disponibilité en répliquant un nœud principal Redis vers un ou plusieurs nœuds d'instances dupliquées. Les modifications apportées aux données du nœud principal sont copiées dans l'instance dupliquée à l'aide du protocole de réplication asynchrone Redis. En raison de la nature asynchrone de la réplication, une instance dupliquée peut impliquer un délai de réplication par rapport au nœud principal, en fonction du taux d'écriture sur l'instance principale.
En cas de défaillance de l'instance principale, l'instance bascule automatiquement vers une instance dupliquée. Pour les instances configurées avec plusieurs instances dupliquées, l'instance bascule automatiquement vers une instance dupliquée avec le délai de réplication le plus faible.
Si une instance est configurée avec une seule instance dupliquée non lue, toutes les connexions d'application sont dirigées vers le point de terminaison principal. Si une instance est configurée à l'aide d'instances dupliquées avec accès en lecture, les applications peuvent également exploiter le point de terminaison de lecture pour répartir les requêtes de lecture sur toutes les instances dupliquées.
Lorsqu'un basculement est déclenché
Un basculement se produit lorsque le nœud Redis principal échoue. Lors d'un basculement, le point de terminaison principal et le point de terminaison de lecture redirigent automatiquement vers le nouveau nœud principal et les nouvelles instances dupliquées. Toutes les connexions au point de terminaison principal sont supprimées, et les connexions de point de terminaison de lecture à l'instance dupliquée avec accès en lecture qui sont promues sont également supprimées.
Impact d'un basculement sur votre application
Lorsque le nœud principal bascule vers l'instance dupliquée, les connexions existantes au point de terminaison principal de l'instance sont supprimées. L'instance est indisponible pendant quelques secondes tandis que la nouvelle instance principale se reconnecte. Toutefois, lors de la reconnexion, votre application est automatiquement redirigée vers le nouveau nœud principal à l'aide de la même chaîne de connexion ou de la même adresse IP. Vous n'avez pas besoin de mettre à jour l'application après un basculement.
Lors du basculement, si des connexions au point de terminaison avec accès en lecture sont établies, les connexions à l'instance dupliquée promues en instance principale sont supprimées. Les connexions aux autres instances dupliquées continuent à être diffusées pendant le basculement. Une fois le basculement terminé et la nouvelle instance dupliquée disponible, les connexions sont redirigées vers la nouvelle instance dupliquée.
Nouvelle tentative de connexion à l'instance après le basculement
Lorsqu'un basculement se produit, toutes les connexions du point de terminaison principal sont supprimées et, en fonction du nombre d'instances dupliquées, certaines connexions avec accès en lecture sont interrompues.
En raison de cette perte de connexion, l'application doit effectuer une nouvelle tentative pour rétablir la connexion. La logique de nouvelle tentative doit utiliser l'intervalle exponentiel entre les tentatives pour garantir que vous ne surchargez pas votre instance avec un trop grand nombre de tentatives de requête. Outre la logique de nouvelle tentative, vous devez tester l'impact d'un basculement sur votre application en la testant avec un basculement manuel.
La plupart des clients Redis intègrent des fonctionnalités de nouvelle tentative que vous devez exploiter en cas de perte de connexion due au basculement.
Un basculement se produit dans les scénarios suivants :
- Procéder au scaling d'une instance
- Mettre à niveau la version de Redis d'une instance
- Lancer un basculement manuel
- Mises à jour de maintenance
Si vous mettez en œuvre une logique de répétition dans votre application pour gérer les pertes de connexion en raison de basculements, votre instance ne devrait pas subir d'impact significatif sur les performances. Généralement, les problèmes ne surviennent que si la logique de nouvelle tentative n'est pas mise en place.
Comment afficher l'état pour la haute disponibilité
Vous pouvez afficher 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 les pages Surveiller des instances Redis et Métriques de surveillance.
Pour en savoir plus sur l'utilisation de la suite Google Cloud Operations avec Google Cloud, consultez la documentation de Cloud Monitoring.
Pour afficher l'état de la réplication native fournie par Redis, vous pouvez émettre la commande INFO de Redis vers l'instance Memorystore pour Redis.