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

---

Remarque : Ce document ou cette section inclut des références à un ou plusieurs termes que Google considère comme irrespectueux ou choquants. Ces termes sont utilisés parce qu'ils constituent des mots clés utilisés par le logiciel décrit dans le présent document.

Ce tutoriel décrit un processus complet de basculement et de remplacement pour la reprise après sinistre (DR) dans Cloud SQL pour MySQL à l'aide d'instances dupliquées interrégionales avec accès en lecture.

Dans ce tutoriel, vous allez configurer une instance Cloud SQL pour MySQL haute disponibilité (HA) pour la reprise après sinistre et simuler une indisponibilité du service. Vous suivrez ensuite la procédure de reprise après sinistre pour récupérer votre déploiement initial une fois la panne résolue.

Important : Ce tutoriel ne s'applique qu'à la reprise après sinistre générale, qui est disponible pour toutes les instances Cloud SQL pour MySQL. Si vous utilisez l'édition Cloud SQL Enterprise Plus, vous avez la possibilité d'utiliser la reprise après sinistre avancée. Pour en savoir plus sur la reprise après sinistre avancée, consultez les pages Reprise après sinistre avancée et Utiliser la reprise après sinistre avancée. La reprise après sinistre avancée est disponible en preview.

Ce tutoriel est destiné aux architectes, aux administrateurs et aux ingénieurs de bases de données.

Pour lire une présentation du fonctionnement de la reprise après sinistre SQL, consultez la page À propos de la reprise après sinistre dans Cloud SQL.

Objectifs

• Créer une instance Cloud SQL pour MySQL haute disponibilité
• Déployer une instance dupliquée interrégionale avec accès en lecture sur Google Cloud à l'aide de Cloud SQL pour MySQL
• Simuler un sinistre et effectuer un basculement avec Cloud SQL pour MySQL
• Comprendre la procédure à suivre pour récupérer votre déploiement initial en effectuant un remplacement avec Cloud SQL pour MySQL

Ce document traite uniquement des processus de basculement et de remplacement pour la reprise après sinistre entre deux régions différentes. Pour plus d'informations sur un processus de basculement d'instance haute disponibilité au sein d'une même région, consultez la page Présentation de la configuration de la haute disponibilité.

Coûts

Dans ce document, vous utilisez les composants facturables suivants de Google Cloud :

• Cloud SQL

Obtenez une estimation des coûts en fonction de votre utilisation prévue à l'aide du simulateur de coût. Les nouveaux utilisateurs de Google Cloud peuvent bénéficier d'un essai gratuit.

Une fois que vous avez terminé les tâches décrites dans ce document, vous pouvez éviter de continuer à payer des frais en supprimant les ressources que vous avez créées. Pour en savoir plus, consultez la section Effectuer un nettoyage.

Avant de commencer

1. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

   Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

   Go to project selector

2. Make sure that billing is enabled for your Google Cloud project.

3. In the Google Cloud console, activate Cloud Shell.

   Activate Cloud Shell

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.

Phase initiale
Nom de l'instance	Rôle	Région
instance-1	Principal	us-west1
instance-2	Instance de secours	us-west1
instance-3	Instance dupliquée interrégionale avec accès en lecture	us-west2

Phase de sinistre
Nom de l'instance	Rôle	Région
instance-3	Principal	us-west2
instance-4	Instance de secours	us-west2
instance-5	Instance dupliquée interrégionale avec accès en lecture	us-west3
instance-6	Instance dupliquée interrégionale avec accès en lecture	us-west1

Phase de remplacement (phase finale)
Nom de l'instance	Rôle	Région
instance-6	Principal	us-west1
instance-7	Instance de secours	us-west1
instance-8	Instance dupliquée interrégionale avec accès en lecture	us-west2

Remarque : Les noms d'instance "instance-2", "instance-4" et "instance-7" ne sont pas utilisés pour créer des instances Cloud SQL. Ces instances sont créées automatiquement lors de l'activation de la haute disponibilité sur les instances "instance-1", "instance-3" et "instance-6". Les noms supplémentaires doivent permettre de faire référence aux instances à haute disponibilité créées automatiquement et d'avoir un schéma de nommage cohérent correspondant aux instances Cloud SQL en cours de création.

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.

Exécution manuelle	Exécution automatique
Avantages : Vous disposez d'un contrôle strict sur chaque étape. Vous pouvez voir, résoudre et signaler immédiatement un problème dans le processus. Vous pouvez visualiser et examiner chaque étape du processus au cours d'un basculement.	Avantages : Vous pouvez mettre en œuvre et tester des processus de basculement. L'automatisation permet une implémentation plus rapide et réduit les délais. La mise en œuvre est totalement indépendante des opérateurs humains, de leurs compétences et de leur disponibilité.
Inconvénients : La mise en œuvre manuelle des étapes du processus peut le ralentir. Les erreurs de saisie humaine peuvent poser des problèmes. Les procédures de test impliquent généralement plusieurs rôles et durent un certain temps, ce qui peut décourager l'exécution de tests réguliers.	Inconvénients : En cas d'erreur imprévue, vous devez procéder à un débogage pendant le basculement en production. Si vous rencontrez des erreurs au cours du processus, vous avez besoin de scripts pour récupérer le processus lorsqu'il s'est arrêté. Une bonne connaissance du script et de sa mise en œuvre est nécessaire pour comprendre le comportement du script, en particulier dans les situations d'erreur.

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.

Effectuer un nettoyage

Pour éviter que les ressources utilisées dans ce tutoriel soient facturées sur votre compte Google Cloud, vous pouvez supprimer le projet Google Cloud que vous avez créé pour ce tutoriel.

Supprimer le projet

Attention : La suppression d'un projet entraîne les effets décrits ci-dessous :

• Tout le contenu du projet est supprimé. Si vous avez utilisé un projet existant pour les tâches décrites dans ce document et que vous le supprimez, vous supprimerez également tout autre travail effectué dans le projet.
• Les ID de projets personnalisés sont perdus. Lorsque vous avez créé ce projet, vous avez peut-être créé un ID de projet personnalisé que vous souhaitez utiliser à l'avenir. Pour conserver les URL qui utilisent l'ID de projet, telle qu'une URL appspot.com, supprimez les ressources sélectionnées dans le projet au lieu de supprimer l'ensemble du projet.

Si vous envisagez d'explorer plusieurs architectures, tutoriels et guides de démarrage rapide, réutiliser des projets peut vous aider à ne pas dépasser les limites de quotas des projets.

1. In the Google Cloud console, go to the Manage resources page.

   Go to Manage resources

2. In the project list, select the project that you want to delete, and then click Delete.
3. In the dialog, type the project ID, and then click Shut down to delete the project.

Étape suivante

• Documentez-vous sur la reprise après sinistre Cloud SQL.
• Documentez-vous sur la reprise après sinistre pour MySQL sur Compute Engine.
• Découvrez les architectures de reprise après sinistre en cas d'indisponibilité de l'infrastructure cloud.
• Découvrez des architectures de référence, des schémas et des bonnes pratiques concernant Google Cloud. Consultez notre Centre d'architecture cloud.