Cette page présente le basculement manuel pour Memorystore pour Redis. Pour savoir comment effectuer un basculement, consultez la page Lancer un basculement manuel.
Qu'est-ce qu'un basculement manuel ?
Une instance Memorystore pour Redis de niveau standard utilise un nœud dupliqué pour sauvegarder le nœud principal. Lorsque le nœud principal n'est plus opérationnel, un basculement normal se produit et le nœud dupliqué est désigné comme nouveau nœud principal. Un basculement manuel est différent d'un basculement normal, car vous l'initialisez vous-même. Pour plus d'informations sur le fonctionnement de la réplication Memorystore pour Redis, consultez la page Haute disponibilité.
Pourquoi initier un basculement manuel ?
L'initiation d'un basculement manuel vous permet de tester la réponse de votre application à un basculement. Ces informations peuvent vous assurer un processus de basculement plus fluide si un basculement inattendu venait à se produire ultérieurement.
Modes optionnels de protection des données
Les deux modes de protection des données disponibles sont les suivants :
- Mode
limited-data-loss(par défaut). - Mode
force-data-loss.
Pour définir le mode de protection des données, utilisez l'une des commandes suivantes:
gcloud redis instances failover INSTANCE_NAME --data-protection-mode=limited-data-loss
ou
gcloud redis instances failover INSTANCE_NAME --data-protection-mode=force-data-loss
Fonctionnement des modes de protection des données
Le mode limited-data-loss minimise la perte de données en vérifiant que la différence de données entre l'instance principale et l'instance répliquée est inférieure à 30 Mo avant de lancer le basculement. Le décalage sur l'instance principale est incrémenté pour chaque octet de données à synchroniser avec ses instances répliquées. En mode limited-data-loss, le basculement est annulé si le delta de décalage le plus élevé entre l'instance principale et chaque instance répliquée est supérieur ou égal à 30 Mo. Si vous pouvez tolérer davantage de pertes de données et que vous souhaitez exécuter le basculement de manière agressive, essayez de définir le mode de protection des données sur force-data-loss.
Le mode force-data-loss utilise une chaîne de stratégies de basculement pour exécuter le basculement de manière agressive. Elle ne vérifie pas le delta de décalage entre l'instance principale et l'instance répliquée avant de lancer le basculement. Vous risquez de perdre plus de 30 Mo de modifications de données.
Métrique d'octets en attente de réplication
La métrique d'octets en attente de réplication vous indique le nombre d'octets que le nœud dupliqué doit encore copier avant que le nœud principal ne soit entièrement sauvegardé. Vous constaterez peut-être une augmentation du nombre d'octets en attente, car l'instance principale se réplique vers l'instance dupliquée lors d'un basculement. Si le basculement est déclenché par une erreur matérielle, il est possible que le nombre d'octets en attente de réplication soit vide, car la valeur de décalage n'a pas pu être obtenue tant que la nouvelle instance répliquée n'a pas été réparée à partir de l'erreur de l'hôte.
Vous pouvez accéder à cette métrique dans la console Google Cloud, sur la page "Détails de l'instance". Pour afficher la page des détails sur l'instance, cliquez sur l'ID d'instance dans la page Liste des instances du projet.
Vous pouvez également accéder à l'explorateur de métriques de votre projet et rechercher la métrique redis.googlapis.com/replication/offset_diff.
Quand exécuter un basculement manuel ?
Les basculements manuels utilisant le mode de protection limited-data-loss par défaut ne réussissent que si la métrique bytes attente réplication est inférieure à 30 Mo. Si vous souhaitez exécuter un basculement manuel avec des octets en attente de réplication supérieurs à 30 Mo, utilisez le mode de protection force-data-loss.
Si vous essayez de conserver autant de données que possible, arrêtez temporairement l'écriture de votre application sur l'instance Redis et n'exécutez le basculement manuel que lorsque la métrique d'octets en attente de réplication atteint la valeur la plus basse que vous jugiez acceptable.
Problèmes potentiels pouvant bloquer un basculement manuel
L'exécution d'un basculement manuel sur une instance de niveau de base ne fonctionne pas, car les instances de niveau de base ne disposent pas d'instances répliquées sur lesquelles l'instance principale peut basculer.
Si l'instance Redis n'est pas opérationnelle, une opération de basculement manuel entraînant une perte de données limitée échoue, car elle est bloquée pour minimiser la perte de données.
Si vous exécutez un script Lua qui s'exécute indéfiniment, vous devez utiliser
force-data-losspour lancer un basculement. Dans ce cas, une opération de basculement en cas de perte limitée des données ne s'achèvera pas correctement.Si des opérations incomplètes sont en attente dans votre instance, telles qu'une mise à l'échelle ou une mise à jour, l'opération de basculement manuel est bloquée. Vous devez attendre que votre instance soit à l'état
READYpour pouvoir exécuter un basculement manuel.
Connexion à une application client
Lorsque le nœud principal bascule sur le nœud dupliqué, les connexions existantes à Memorystore pour Redis sont supprimées. Toutefois, au moment 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.
Vérifier un basculement manuel
Vous pouvez vérifier la réussite d'une opération de basculement manuel à l'aide de la console Google Cloud ou d'gcloud.
Validation via la console Google Cloud
Avant de lancer un basculement manuel, accédez à la page Liste des instances de Memorystore pour Redis, puis cliquez sur le nom de votre instance.
Ensuite, dans l'onglet Configuration, à côté de l'option Emplacement principal, affichez la zone dans laquelle se trouve votre nœud principal. Notez la zone. Consultez à nouveau cette page une fois le basculement manuel terminé pour vérifier que le nœud principal a changé de zone.
Validation avec Cloud Monitoring
Pour afficher les métriques d'une ressource surveillée à l'aide de l'explorateur de métriques, procédez comme suit :
-
Dans le panneau de navigation de la console Google Cloud, sélectionnez Surveillance, puis leaderboard Explorateur de métriques :
- Dans l'élément Métrique, développez le menu Sélectionner une métrique, saisissez
Node roledans la barre de filtre, puis utilisez les sous-menus pour sélectionner un type de ressource et des métriques spécifiques :- Dans le menu Ressources actives, sélectionnez Cloud Memorystore Redis.
- Dans le menu Catégories de métriques actives, sélectionnez Réplication.
- Dans le menu Métriques actives, sélectionnez Rôle de nœud.
- Cliquez sur Appliquer.
Pour supprimer des séries temporelles de l'affichage, utilisez l'élément Filtre.
Pour combiner des séries temporelles, utilisez les menus de l'élément Agrégation. Par exemple, pour afficher l'utilisation du processeur pour vos VM en fonction de leur zone, définissez le premier menu sur Moyenne et le second sur zone.
Toutes les séries temporelles sont affichées lorsque le premier menu de l'élément Agrégation est défini sur Non agrégé. Les paramètres par défaut de l'élément Aggregation (Agrégation) sont déterminés par le type de métrique que vous avez sélectionné.
- Pour le quota et les autres métriques qui indiquent un échantillon par jour, procédez comme suit :
- Dans le volet Affichage, définissez le type de widget sur Graphique à barres empilées.
- Définissez la période sur au moins une semaine.
Le graphique Cloud Monitoring représente le nœud principal et le nœud dupliqué sur deux lignes. Lorsque la ligne d'un nœud a la valeur zéro sur le graphique, il s'agit du nœud dupliqué. Lorsque la ligne d'un nœud a une valeur de 1 sur le graphique, il s'agit du nœud principal. Le graphique représente un basculement en indiquant comment les lignes sont passées respectivement de un à zéro et de zéro à un.
Validation du gcloud
Avant d'initier un basculement manuel, exécutez la commande suivante pour vérifier la zone dans laquelle se trouve le nœud principal :
gcloud redis instances describe [INSTANCE_ID] --region=[REGION]
Le nœud principal se trouve dans la zone intitulée currentLocationId. Prenez note de cette zone.
Après avoir effectué un basculement manuel, vous pouvez confirmer que votre nœud principal est passé à une nouvelle zone en exécutant à nouveau la commande gcloud redis instances describe et en vérifiant que currentLocationId a modifié les zones.
De plus, le libellé locationId vous indique la zone dans laquelle vous avez initialement provisionné le nœud principal. Le libellé alternativeLocationId vous indique la zone dans laquelle le système a initialement provisionné le nœud dupliqué. Chaque fois qu'un basculement se produit, le nœud principal et le nœud dupliqué basculent d'une zone à l'autre. Cependant, les zones associées à locationId et alternativeLocationId ne changent pas.