À propos du 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)
  • 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 le de données entre l'instance principale et l'instance répliquée est inférieure à 30 Mo avant à l'origine du basculement. Le décalage sur l'instance principale est incrémenté pour chaque octet de données qui doivent être synchronisées avec ses instances répliquées. Dans le limited-data-loss le basculement s'interrompt si le delta le plus élevé entre l'instance principale dont la taille est supérieure ou égale à 30 Mo. Si vous pouvez tolérer davantage de pertes de données et que vous souhaitez pour 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 de façon agressive le basculement. Il ne vérifie pas le delta de décalage entre le principal et les réplicas avant de lancer le basculement. Vous pouvez potentiellement 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 pouvez observer une augmentation du nombre d'octets en attente pendant la réplication de l'instance principale vers l'instance répliquée un basculement. Si le basculement est déclenché par une erreur matérielle, il est possible que vous constatiez un espace vide dans les octets en attente de réplication, car la valeur de décalage n'a pas pu être obtenue tant que la nouvelle instance répliquée n'a pas été corrigée.

Vous pouvez y accéder 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 l'option Basic Les instances de niveau supérieur n'ont pas d'instances répliquées vers lesquelles l'instance principale peut basculer.

  • Si votre instance Redis n'est plus opérationnelle, une opération de basculement manuel avec perte de données limitée échoue, car elle est bloquée pour limiter la perte de données.

  • Si vous exécutez un script Lua qui s'exécute indéfiniment, vous devez utiliser force-data-loss pour déclencher un basculement. Dans ce cas, une opération de basculement avec perte de données limitée ne sera pas effectué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 la réussite d'une opération de basculement manuel avec la console Google Cloud ou gcloud.

Validation avec 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 Emplacement principal, consultez la zone dans laquelle se trouve votre nœud principal. Notez la zone. Consultez à nouveau cette page lorsque vous terminez votre basculement manuel pour confirmer 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 :

  1. Dans la console Google Cloud, accédez à la page Explorateur de métriques :

    Accéder à l'explorateur de métriques

    Si vous utilisez la barre de recherche pour trouver cette page, sélectionnez le résultat dont le sous-titre est Monitoring.

  2. Dans l'élément Métrique, 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 des métriques spécifiques :
    1. Dans le menu Ressources actives, sélectionnez Cloud Memorystore 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.

  3. Pour supprimer des séries temporelles de l'affichage, utilisez l'élément Filtre.

  4. 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é.

  5. Pour le quota et les autres métriques qui indiquent un échantillon par jour, procédez comme suit :
    1. Dans le volet Affichage, définissez le type de widget sur Graphique à barres empilées.
    2. 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.