Basculement manuel

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).
    • Le basculement manuel s'exécute toujours en mode de perte de données limitée, à moins que vous ne changiez le mode.
  • Mode force-data-loss.

Pour changer le mode de protection des données, utilisez l’une des commandes suivantes :

gcloud redis instances failover INSTANCE_NAME --data-protection-mode=force-data-loss

ou

gcloud redis instances failover INSTANCE_NAME --data-protection-mode=limited-data-loss

Fonctionnement des modes de protection des données

Si vous souhaitez tester le comportement de votre application dans un scénario de basculement réel, vous pouvez utiliser le mode force-data-loss, car il représente plus précisément les conditions d'un basculement lors d'une reprise après sinistre.

Tout basculement du nœud principal vers le nœud dupliqué peut entraîner une perte de données. Le mode limited-data-loss limite cette perte de données en vérifiant que la différence de synchronisation entre le nœud principal et le nœud dupliqué est inférieure à 30 Mo avant de lancer le basculement.

Le mode force-data-loss ignore cette vérification lors de la synchronisation entre le nœud principal et le nœud dupliqué. Si vous utilisez le mode force-data-loss lorsque la synchronisation du nœud dupliqué a plus de 30 Mo de retard sur le nœud principal, vous risquez de perdre 30 Mo de données ou plus.

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 une augmentation du nombre d'octets en attente lorsque l'instance principale est répliquée sur l'instance dupliquée lors d'un basculement.

Vous pouvez accéder à cette métrique dans Google Cloud Console, sur la page des 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 la suite Google Cloud Operations pour 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 n'ont pas d'instances dupliquées.

  • Si votre instance Redis n'est plus opérationnelle, l'opération de basculement manuel est bloquée.

  • 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 READY pour 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 le succès d'une opération de basculement manuel avec Google Cloud Console, la suite Google Cloud Operations ou gcloud.

Validation dans Google Cloud Console

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, sous Propriétés de l'instance, consultez les zones dans lesquelles se trouvent le nœud principal et le nœud dupliqué. Prenez note de ces zones. Consultez à nouveau cette page lorsque vous terminez votre basculement manuel pour confirmer que le nœud principal et le nœud dupliqué ont bien 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 :

  1. Dans Google Cloud Console, accédez à la page Explorateur de métriques de Monitoring.
  2. Accéder à l'explorateur de métriques

  3. Dans la barre d'outils, sélectionnez l'onglet Explorateur.
  4. Accédez à l'onglet Configuration.
  5. Développez le menu Sélectionner une métrique, saisissez Node role dans la barre de filtre, puis utilisez les sous-menus pour sélectionner un type de ressource et une métrique spécifiques :
    1. Dans le menu Ressources actives, sélectionnez Cloud Memorystore pour Redis.
    2. Dans le menu Catégories de métriques actives, sélectionnez Réplication.
    3. Dans le menu Métriques actives, sélectionnez Rôle du nœud.
    4. Cliquez sur Appliquer.
  6. Facultatif : pour configurer l'affichage des données, ajoutez des filtres et utilisez les menus Grouper par, Agrégateur et type de graphique. Par exemple, vous pouvez grouper les données par libellé de ressource ou de métrique. Pour plus d'informations, consultez la section Sélectionner des métriques lors de l'utilisation de l'explorateur de métriques.
  7. Facultatif : modifiez les paramètres du graphique :
    • Pour le quota et les autres métriques qui indiquent un échantillon par jour, définissez la période sur au moins une semaine et définissez le type de tracé sur Graphique à barres empilées.
    • Pour les métriques à valeur de distribution, définissez le type de tracé sur Graphique de carte de densité.

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.