Reprise après sinistre de Cloud SQL pour MySQL : processus complet de basculement et de remplacement

Phase 1 : Configurer une instance de base de données à haute disponibilité pour la reprise après sinistre

Les phases suivantes (1 à 3) vous guident dans un processus complet de basculement et de remplacement. Vous exécutez toutes les commandes à l'aide de la commande gcloud dans Cloud Shell. Pour simplifier le processus, le tutoriel utilise, dans la mesure du possible, les paramètres par défaut (par exemple, la version Cloud SQL par défaut). Dans votre environnement de production, vous pouvez ajouter d'autres configurations.

Définir des variables d'environnement

Cette section fournit des exemples de variables d'environnement qui définissent les différents noms et régions requis pour les commandes que vous exécutez dans ce tutoriel. Vous pouvez ajuster ces exemples de variables selon vos besoins.

Les tableaux suivants indiquent les noms des instances, leurs rôles et leurs régions de déploiement pour chaque phase du processus de reprise après sinistre et de remplacement décrit dans ce tutoriel. Vous pouvez également indiquer vos propres noms et régions.

Les noms d'instance dans les tables précédentes ne sont pas encodés avec leur rôle. En situation de reprise après sinistre, la fonction d'une instance peut changer. Par exemple, une instance dupliquée peut devenir l'instance principale. Si le nom de la nouvelle instance principale contient le mot replica, une confusion et des conflits peuvent survenir. Par conséquent, nous vous recommandons de ne pas encoder les noms d'instance avec la fonction ou le rôle que vous leur attribuez à l'origine.

Les tableaux précédents répertorient les noms des instances de secours. Même si ce tutoriel ne traite pas du basculement d'instance haute disponibilité, il inclut les noms des instances de secours à des fins d'exhaustivité.

La phase de remplacement recrée le déploiement d'origine de la phase initiale dans les mêmes régions d'origine. Notez toutefois que, dans une opération de remplacement, les noms des instances doivent changer, car les noms d'origine ne redeviennent pas immédiatement disponibles après la suppression des instances d'origine. Pour faciliter la création des instances lors de la phase de remplacement, vous devez utiliser des noms d'instances qui ne correspondent pas aux noms utilisés lors de la phase initiale.

• Dans Cloud Shell, définissez des variables d'environnement basées sur les spécifications décrites dans les tableaux précédents :

  export primary_name=instance-1
  export primary_tier=db-n1-standard-2
  export primary_region=us-west1
  export primary_root_password=my-root-password
  export primary_backup_start_time=22:00
  export cross_region_replica_name=instance-3
  export cross_region_replica_region=us-west2
  

  Si vous souhaitez utiliser un autre niveau pour votre instance principale, répertoriez les niveaux disponibles, puis attribuez une valeur différente au niveau principal (primary_tier) :

  gcloud sql tiers list
  

  Pour obtenir la liste des régions dans lesquelles vous pouvez déployer Cloud SQL, consultez la page Paramètres des instances.

Créer une instance de base de données principale

1. Dans Cloud Shell, créez une instance unique de Cloud SQL :

   gcloud sql instances create $primary_name \
       --tier=$primary_tier \
       --region=$primary_region
   

   La commande gcloud se met en pause jusqu'à ce que l'instance soit créée.

2. Définissez le mot de passe racine :

   gcloud sql users set-password root \
       --host=% \
       --instance $primary_name \
       --password $primary_root_password
   

Créer une base de données principale

1. Dans Cloud Shell, connectez-vous à l'interface système MySQL et saisissez le mot de passe racine lorsque l'invite s'affiche :

   gcloud sql connect $primary_name --user=root
   

2. À l'invite MySQL, créez une base de données et importez des données de test :

   CREATE DATABASE guestbook;
   
   USE guestbook;
   
   CREATE TABLE entries (guestName VARCHAR(255), content VARCHAR(255), entryID INT NOT NULL AUTO_INCREMENT, PRIMARY KEY(entryID));
   
   INSERT INTO entries (guestName, content) values ("first guest", "I got here!");
   INSERT INTO entries (guestName, content) values ("second guest", "Me too!");
   

3. Vérifiez que les données ont bien été validées :

   SELECT * FROM entries;
   

   Vérifiez que deux lignes de données sont renvoyées.

4. Quittez l'interface système MySQL :

   exit;
   

À ce stade, vous disposez d'une base de données unique contenant une table et des données de test.

Convertir l'instance principale en instance de base de données à haute disponibilité

Vous ne pouvez configurer Cloud SQL qu'en tant que système à haute disponibilité régional, et non en tant que système interrégional. (la configuration d'une instance dupliquée interrégionale avec accès en lecture est différente de la configuration de Cloud SQL en tant que système interrégional). Pour en savoir plus, consultez la page Activer et désactiver la haute disponibilité sur une instance.

• Dans Cloud Shell, créez une instance Cloud SQL compatible avec la haute disponibilité :

  gcloud sql instances patch $primary_name \
      --availability-type REGIONAL \
      --enable-bin-log \
      --backup-start-time=$primary_backup_start_time
  

Ajouter une instance dupliquée interrégionale avec accès en lecture pour la reprise après sinistre avec mise à jour automatique

Les étapes suivantes sont suffisantes pour créer une instance dupliquée interrégionale avec accès en lecture pour ce tutoriel :

1. Dans Cloud Shell, configurez une instance dupliquée interrégionale avec accès en lecture :

   gcloud sql instances create $cross_region_replica_name \
       --master-instance-name=$primary_name \
       --region=$cross_region_replica_region
   

2. (Facultatif) Pour vérifier que la base de données a bien été répliquée, accédez à la page des Instances Cloud SQL dans la console Google Cloud.

   Accéder à la page "Instances"

   

   La console Google Cloud indique que l'instance principale (instance-1) est activée pour la haute disponibilité et qu'une instance dupliquée interrégionale avec accès en lecture (instance-3) existe.

3. En utilisant le même mot de passe racine que pour l'instance principale, connectez-vous à l'instance dupliquée interrégionale avec accès en lecture :

   gcloud sql connect $cross_region_replica_name --user=root
   

4. Lorsque MySQL vous y invite, sélectionnez les données pour vous assurer que la réplication fonctionne :

   USE guestbook;
   
   SELECT * FROM entries;
   

5. Quittez l'interface système MySQL :

   exit;
   

Pour savoir comment configurer une instance dupliquée interrégionale avec accès en lecture complet, consultez la documentation de Cloud SQL.

Pour les bases de données volumineuses exploitées en environnement de production, nous vous recommandons de sauvegarder la base de données principale et de créer l'instance dupliquée interrégionale avec accès en lecture à partir de la sauvegarde. Cette étape permet de réduire le temps nécessaire pour synchroniser l'instance dupliquée avec accès en lecture à la base de données principale. Ce processus est décrit dans la section suivante. Vous pouvez toutefois ignorer cette étape et passer directement à la phase 2 si vous le souhaitez.

Ajouter une instance dupliquée interrégionale avec accès en lecture basée sur un fichier de vidage

Une façon d'optimiser la création d'une instance dupliquée interrégionale avec accès en lecture consiste à synchroniser l'instance dupliquée à partir d'un état antérieur cohérent de la base de données principale, plutôt que de la synchroniser avec l'état de la base principale au moment où l'instance dupliquée devient la nouvelle instance principale. Cette optimisation nécessite la création d'un fichier de vidage que l'instance dupliquée utilise comme état de départ.

Pour connaître les étapes de création d'une instance dupliquée basée sur un fichier de vidage, consultez la page Réplication depuis un serveur externe vers Cloud SQL (v1.1). Cette approche peut être utile pour les bases de données de production volumineuses. Toutefois, dans ce tutoriel, nous ignorons cette étape, car l'ensemble de données de test est suffisamment petit pour une réplication complète.

Phase 2 : Simuler un sinistre (interruption de la région)

Au cours de cette phase, vous allez simuler la panne d'une région principale dans un environnement de production en rendant la base de données principale indisponible.

Déterminer la latence de l'instance dupliquée interrégionale avec accès en lecture

Dans les étapes suivantes, vous allez déterminer le délai de réplication de l'instance dupliquée interrégionale avec accès en lecture :

1. Dans la console Google Cloud, accédez à la page Instances Cloud SQL.

   Accéder à la page "Instances"

2. Cliquez sur l'instance dupliquée avec accès en lecture (instance-3).

3. Dans la liste déroulante des métriques, cliquez sur Replication Lag (Délai de réplication) :

   

   La métrique affichée est désormais Replication Lag (Délai de réplication). Le graphique ne montre aucun délai :

   

Dans l'idéal, le délai de réplication doit être nul lorsqu'une indisponibilité de région principale survient. En effet, un retard nul garantit que toutes les transactions sont bien répliquées. Si ce délai n'est pas nul, certaines transactions peuvent ne pas être répliquées. En pareil cas, l'instance dupliquée interrégionale avec accès en lecture ne contient pas toutes les transactions validées sur l'instance principale.

Rendre l'instance principale indisponible

Dans les étapes suivantes, vous allez simuler un sinistre en arrêtant l'instance principale. Si une instance dupliquée interrégionale avec accès en lecture est associée à l'instance principale, vous devez d'abord dissocier l'instance dupliquée, sinon vous ne pourrez pas arrêter l'instance Cloud SQL.

1. Dans Cloud Shell, dissociez l'instance dupliquée interrégionale avec accès en lecture de l'instance principale.

   gcloud sql instances patch $cross_region_replica_name \
       --no-enable-database-replication
   

   Lorsque vous y êtes invité, acceptez l'option permettant de continuer.

2. Arrêtez l'instance de base de données principale :

   gcloud sql instances patch $primary_name --activation-policy NEVER
   

Mettre en œuvre la reprise après sinistre

1. Dans Cloud Shell, convertissez l'instance dupliquée interrégionale avec accès en lecture en instance autonome :

   gcloud sql instances promote-replica $cross_region_replica_name
   

   Lorsque vous y êtes invité, acceptez l'option permettant de continuer. Sur la page des Instances Cloud SQL, on peut voir que l'ancienne instance dupliquée interrégionale avec accès en lecture (instance-3) est répertoriée en tant que nouvelle instance principale, et que l'ancienne instance principale (instance-1) est bien considérée comme arrêté :

   

   Après avoir promu l'instance dupliquée interrégionale avec accès en lecture en tant que nouvelle instance principale, activez-la pour la haute disponibilité. Il est recommandé de mettre à jour les variables d'environnement avec un nom approprié.

2. Mettez à jour les variables d'environnement :

   export former_primary_name=$primary_name
   export primary_name=$cross_region_replica_name
   export primary_tier=db-n1-standard-2
   export primary_region=$cross_region_replica_region
   export primary_root_password=my-root-password
   export primary_backup_start_time=22:00
   export cross_region_replica_name=instance-5
   export cross_region_replica_region=us-west3
   

3. Démarrez la nouvelle instance principale :

   gcloud sql instances patch $primary_name --activation-policy ALWAYS
   

4. Activez la nouvelle instance principale en tant qu'instance régionale à haute disponibilité :

   gcloud sql instances patch $primary_name \
       --availability-type REGIONAL \
       --enable-bin-log \
       --backup-start-time=$backup_start_time
   

5. Créez une instance dupliquée interrégionale avec accès en lecture dans une troisième région :

   gcloud sql instances create $cross_region_replica_name \
       --master-instance-name=$primary_name \
       --region=$cross_region_replica_region
   

   Dans une étape précédente, vous avez défini la variable d'environnement cross_region_replica_region sur us-west3.

   Une fois le basculement terminé, la page Instances Cloud SQL dans la console Google Cloud indique que la nouvelle instance principale (instance-3) est activée pour la haute disponibilité et comporte une instance dupliquée interrégionale avec accès en lecture (instance-5) :

   

6. (Facultatif) Si vous disposez de sauvegardes régulières, suivez le processus décrit précédemment pour synchroniser la nouvelle instance principale avec la dernière version de sauvegarde.

7. (Facultatif) Si vous utilisez un proxy Cloud SQL, configurez-le de manière à utiliser la nouvelle instance principale afin de reprendre le traitement de l'application.

Gérer une indisponibilité régionale temporaire

Il est possible que l'indisponibilité qui déclenche un basculement soit résolue avant l'achèvement de celui-ci. Dans ce cas, il peut être judicieux d'annuler le processus de basculement et de continuer à utiliser l'instance Cloud SQL principale d'origine dans la région où l'indisponibilité est survenue.

Selon l'état spécifique du processus de basculement, l'instance dupliquée interrégionale avec accès en lecture a peut-être déjà été promue. Dans ce cas, vous devez la supprimer et recréer une instance dupliquée interrégionale avec accès en lecture.

Supprimer l'instance principale d'origine pour éviter une situation de split-brain

Pour éviter une situation de split-brain, vous devez supprimer l'instance principale d'origine (ou la rendre inaccessible aux clients de la base de données).

Après un basculement, une situation de split-brain peut se produire lorsque des clients écrivent simultanément dans la base de données principale d'origine et dans la nouvelle base de données principale. Dans ce cas, un risque d'incohérence entre les contenus des deux bases existe. Après un basculement, la base de données principale d'origine doit être considérée comme obsolète et ne doit recevoir aucun trafic de lecture ou d'écriture.

• Dans Cloud Shell, supprimez l'instance principale d'origine :

  gcloud sql instances delete $former_primary_name
  

  Lorsque vous y êtes invité, acceptez l'option permettant de continuer.

  Dans la console Google Cloud, la page Instances Cloud SQL n'affiche plus l'instance principale d'origine (instance-1) dans le cadre du déploiement :

  

Phase 3 : Mettre en œuvre une solution de remplacement

Pour mettre en œuvre une solution de remplacement pointant vers votre région d'origine (R1) une fois que celle-ci sera à nouveau disponible, suivez la même procédure que celle décrite à la phase 2. Cette procédure peut se résumer comme suit :

1. Créez une deuxième instance dupliquée interrégionale avec accès en lecture dans la région d'origine (R1). À ce stade, l'instance principale dispose de deux instances dupliquées interrégionales avec accès en lecture, une dans la région R3 et une dans la région R1.

2. Promouvez l'instance dupliquée interrégionale avec accès en lecture de la région R1 en tant qu'instance principale finale.

3. Activez la haute disponibilité pour la dernière instance principale.

4. Créez une instance dupliquée interrégionale avec accès en lecture pour l'instance principale finale dans us-west2.

5. Pour éviter une situation de split-brain, supprimez toutes les instances qui ne sont plus nécessaires (instance principale d'origine et instance dupliquée interrégionale avec accès en lecture dans la région R3).

Comme indiqué précédemment, il est recommandé de créer une sauvegarde initiale contenant l'état de départ défini pour la nouvelle base de données principale.

Le déploiement final dispose désormais d'une instance principale haute disponibilité (avec le nom instance-6) et d'une instance dupliquée interrégionale avec accès en lecture (nommée instance-8).

Comparer les avantages et les inconvénients des reprises après sinistre manuelles et automatiques

Le tableau suivant présente les avantages et les inconvénients de la mise en œuvre des processus de reprise après sinistre manuels et automatiques. L'objectif ici n'est pas de déterminer quelle approche est correcte et quelle approche ne l'est pas, mais de fournir des critères pour vous aider à déterminer celle qui est la mieux adaptée à vos besoins.

Nous vous recommandons de commencer avec une mise en œuvre manuelle. Ensuite, exécutez volontairement la mise en œuvre régulièrement (de préférence en production) pour vous assurer que le processus manuel fonctionne et que tous les membres de l'équipe connaissent leurs rôles et leurs responsabilités. Nous vous recommandons de définir votre processus manuel dans un document présentant en détail ses différentes étapes. Après chaque mise en œuvre, vous devez confirmer ou modifier/affiner le document décrivant le processus.

Une fois que vous avez optimisé le processus et que vous êtes sûr de sa fiabilité, vous devez déterminer si vous souhaitez l'automatiser. Si vous sélectionnez et mettez en œuvre un processus automatisé, vous devez le tester régulièrement en production pour vous assurer de pouvoir l'exécuter de manière fiable.