Cette page explique comment utiliser la reprise après sinistre avancée. La reprise après sinistre avancée offre deux fonctionnalités principales :
- Le basculement d'instance répliquée vous permet de basculer immédiatement votre instance principale vers l'instance répliquée de DR en cas de défaillance régionale.
- Le basculement vous permet d'inverser les rôles de l'instance principale et de l'instance répliquée de reprise après sinistre désignée, sans aucune perte de données. Vous pouvez utiliser la commutation pour restaurer un déploiement à son état de déploiement d'origine après le basculement de l'instance répliquée, ou utiliser la commutation pour tester la reprise après sinistre.
La reprise après sinistre avancée n'est compatible qu'avec les instances Cloud SQL Enterprise Plus.
Désigner une instance répliquée de reprise après sinistre
Pour effectuer une reprise après sinistre avancée, vous devez d'abord désigner une instance répliquée interrégionale de reprise après sinistre.
Avant de commencer
Si vous prévoyez d'utiliser le SDK Google Cloud, vous devez utiliser la version 470.0.0 ou ultérieure, ainsi que les commandes gcloud beta
. Pour vérifier la version du SDK Google Cloud, exécutez gcloud --version
. Pour initialiser le SDK Google Cloud, exécutez la commande suivante gcloud components update
.
Pour installer le SDK Google Cloud, consultez la page Installer gcloud CLI.
Conditions requises pour les instances répliquées de DR
L'instance répliquée avec accès en lecture de reprise après sinistre désignée doit répondre aux exigences suivantes :
- Doit être une instance Cloud SQL Enterprise Plus
- Doit être la même version majeure et mineure de base de données que l'instance principale, exécutant MySQL 8.0.31 ou une version ultérieure
- Doit se trouver dans une région distincte de l'instance principale
- doit être une instance répliquée directe avec accès en lecture (ne doit pas être une instance répliquées en cascade)
- Outre l'utilisation des valeurs par défaut, aucune des options suivantes ne peut être configurée pour l'instance répliquée de reprise après sinistre :
replicate_do_db
replicate_ignore_db
replicate_do_table
replicate_wild_do_table
replicate_ignore_table
replicate_wild_ignore_table
- Doit stocker les journaux de transactions utilisés pour la récupération PITR dans Cloud Storage
- Ne peut être une instance répliquée externe
Recommandations concernant les instances répliquées de reprise après sinistre
Cette section fournit des recommandations pour votre instance répliquée de reprise après sinistre. Les recommandations suivantes peuvent vous aider à éviter les problèmes de performances dans votre déploiement :
- Utilisez la même taille de disque que l'instance principale ou activez la croissance automatique.
- Utilisez une configuration haute disponibilité cohérente. Si vous activez la haute disponibilité sur l'instance principale, activez également la haute disponibilité sur l'instance répliquée de DR.
- Utilisez une configuration de cache de données cohérente. Si vous activez le cache de données sur l'instance principale, activez également le cache de données sur l'instance répliquée de DR.
- Configurez les options de base de données appropriées pour votre instance répliquée de DR avant et après toute opération de commutation ou de basculement d'instance répliquée.
Créer une instance répliquée pour répondre aux exigences d'instance répliquée de reprise après sinistre
Si l'instance principale ne dispose pas déjà d'une instance répliquée interrégionale avec accès en lecture répondant aux exigences d'instance répliquée de DR, créez-en une.
Console
-
Dans Google Cloud Console, accédez à la page Instances Cloud SQL.
- Recherchez l'instance principale.
- Dans la colonne Actions, cliquez sur le menu Autres actions.
- Sélectionnez Créer une instance dupliquée avec accès en lecture.
- Dans le champ ID d'instance, saisissez un nom pour l'instance répliquée de DR.
- Dans le champ Version de la base de données,
MySQL 8.0
est déjà sélectionné. - Dans le champ Version mineure, conservez la version mineure présélectionnée. L'instance répliquée de DR et l'instance principale doivent partager la même version mineure de base de données.
- Dans la section Sélectionner une disponibilité régionale et zonale de la page, procédez comme suit :
- Sélectionnez une région différente de celle de votre instance principale.
- Facultatif. Sélectionnez Plusieurs zones pour l'instance répliquée de DR.
- Facultatif. Sélectionnez les zones principales et les zones secondaires de l'instance répliquée de reprise après sinistre.
- Dans la section Personnaliser votre instance de la page, vous pouvez mettre à jour les paramètres de votre instance répliquée de DR. Pour en savoir plus sur chaque paramètre, consultez la page Paramètres des instances.
- Pour Formes de machines, sélectionnez le même type de machine que votre instance principale.
- Pour le champ Options, configurez les options requises pour votre base de données.
- Cliquez sur Créer une instance répliquée.
Cloud SQL crée une sauvegarde de l'instance principale, puis génère l'instance répliquée. Vous revenez à la page de l'instance principale.
gcloud
Pour créer une instance répliquée répondant aux exigences d'une instance répliquée de reprise après sinistre, exécutez la commande suivante :
gcloud sql instances create REPLICA_NAME \ --master-instance-name=PRIMARY_INSTANCE_NAME \ --region=REPLICA_REGION_NAME \ --database-version=DATABASE_VERSION \ --tier=MACHINE_TYPE \ --availability-type=AVAILABILITY_TYPE --edition="ENTERPRISE_PLUS"
Remplacez les variables suivantes :
- REPLICA_NAME : nom de l'instance répliquée de reprise après sinistre.
- PRIMARY_INSTANCE_NAME : nom de l'instance principale.
- REPLICA_REGION_NAME : spécifiez une région différente de celle de l'instance principale.
- DATABASE_VERSION : spécifiez la chaîne de version qui correspond aux versions majeure et mineure de la base de données de l'instance principale, par exemple
MYSQL_8_0_31
.Les versions majeure et mineure de la base de données doivent être identiques pour l'instance répliquée principale et pour l'instance répliuqée de DR.
- MACHINE_TYPE : spécifiez le même type de machine que l'instance principale. Nous recommandons que le type de machine corresponde au type de machine de l'instance principale.
- AVAILABILITY_TYPE : si l'instance principale est configurée pour la haute disponibilité, nous vous recommandons de spécifier
REGIONAL
pour activer la haute disponibilité. - EDITION : indiquez
ENTERPRISE_PLUS
.
REST v1
Avant d'utiliser les données de requête, effectuez les remplacements suivants :
- PRIMARY_INSTANCE_NAME : nom de l'instance principale.
- PROJECT_ID : ID ou numéro de projet du projet Google Cloud de l'instance principale et de l'instance répliquée de DR.
- Chaîne de version DATABASE_VERSION: correspondant à la version majeure et mineure de la base de données de l'instance principale, par exemple
MYSQL_8_0_31
. Les versions majeure et mineure de la base de données doivent être identiques pour l'instance répliquée principale et pour l'instance répliquée de DR. - REPLICA_NAME : nom de l'instance répliquée de reprise après sinistre que vous créez.
- REPLICA_REGION : région de l'instance répliquée de DR. La région de l'instance répliquée doit être différente de celle de l'instance principale.
- MACHINE_TYPE : spécifiez le même type de machine que l'instance principale. Nous vous recommandons de sélectionner le même type de machine que l'instance principale.
- AVAILABILITY_TYPE : si l'instance principale est configurée pour la haute disponibilité, nous vous recommandons de spécifier
REGIONAL
pour activer la haute disponibilité.
Méthode HTTP et URL :
POST https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances
Corps JSON de la requête :
{ "masterInstanceName": "PRIMARY_INSTANCE_NAME", "project": "PROJECT_ID", "databaseVersion": "DATABASE_VERSION", "name": "REPLICA_NAME", "region": "REPLICA_REGION", "settings": { "tier": "MACHINE_TYPE", "availabilityType": "AVAILABILITY_TYPE", "settingsVersion": 0, "replicationType": "ASYNCHRONOUS", } }
Pour envoyer votre requête, développez l'une des options suivantes :
Vous devriez recevoir une réponse JSON de ce type :
REST v1beta4
Avant d'utiliser les données de requête, effectuez les remplacements suivants :
- PRIMARY_INSTANCE_NAME : nom de l'instance principale.
- PROJECT_ID : ID ou numéro de projet du projet Google Cloud de l'instance principale et de l'instance répliquée de DR.
- Chaîne de version DATABASE_VERSION: correspondant à la version majeure et mineure de la base de données de l'instance principale, par exemple
MYSQL_8_0_31
. Les versions majeure et mineure de la base de données doivent être identiques pour l'instance répliquée principale et pour l'instance répliquée de DR. - REPLICA_NAME : nom de l'instance répliquée de reprise après sinistre que vous créez.
- REPLICA_REGION : région de l'instance répliquée de DR. La région de l'instance répliquée doit être différente de celle de l'instance principale.
- MACHINE_TYPE : spécifiez le même type de machine que l'instance principale. Nous vous recommandons d'utiliser une taille de disque identique à celle du disque de l'instance principale.
- AVAILABILITY_TYPE : si l'instance principale est configurée pour la haute disponibilité, nous vous recommandons de spécifier
REGIONAL
pour activer la haute disponibilité.
Méthode HTTP et URL :
POST https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances
Corps JSON de la requête :
{ "masterInstanceName": "PRIMARY_INSTANCE_NAME", "project": "PROJECT_ID", "databaseVersion": "DATABASE_VERSION", "name": "REPLICA_NAME", "region": "REPLICA_REGION", "settings": { "tier": "MACHINE_TYPE", "availabilityType": "AVAILABILITY_TYPE", "settingsVersion": 0, "replicationType": "ASYNCHRONOUS", } }
Pour envoyer votre requête, développez l'une des options suivantes :
Vous devriez recevoir une réponse JSON de ce type :
Désigner l'instance répliquée de reprise après sinistre pour l'instance principale
Les procédures suivantes décrivent comment désigner l'une des instances répliquées interrégionales d'une instance principale comme instance répliquée de reprise après sinistre pour la commutation ou le basculement d'instances répliquées.
Console
Pour désigner une instance répliquée de reprise après sinistre pour une instance principale, procédez comme suit :
-
Dans Google Cloud Console, accédez à la page Instances Cloud SQL.
- Recherchez et sélectionnez l'instance principale. La page Présentation de l'instance principale s'affiche.
- Dans le menu de navigation, cliquez sur Instances répliquées.
- Dans la liste des instances répliquées avec accès en lecture, recherchez l'instance répliquée interrégionale avec accès en lecture que vous souhaitez désigner comme instance répliquée de reprise après sinistre.
- Pour l'instance répliquée, cliquez sur le bouton more_vert Actions, puis sélectionnez Désigner comme instance répliquée de reprise après sinistre.
- Cliquez sur Confirmer.
gcloud
Pour désigner une instance répliquée de DR comme instance principale, exécutez la commande suivante :
gcloud beta sql instances patch PRIMARY_INSTANCE_NAME \ --failover-dr-replica-name=REPLICA_NAME
Remplacez les variables suivantes :
- PRIMARY_INSTANCE_NAME : nom de l'instance principale.
- REPLICA_NAME : nom de l'instance répliquée de reprise après sinistre.
REST v1
Avant d'utiliser les données de requête, effectuez les remplacements suivants :
- PRIMARY_INSTANCE_NAME : nom de l'instance principale.
- REPLICA_NAME : nom de l'instance répliquée de reprise après sinistre.
Méthode HTTP et URL :
PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME
Corps JSON de la requête :
{ "replicationCluster": { "failoverDrReplicaName": "REPLICA_NAME" } }
Pour envoyer votre requête, développez l'une des options suivantes :
Vous devriez recevoir une réponse JSON de ce type :
REST v1beta4
Avant d'utiliser les données de requête, effectuez les remplacements suivants :
- PRIMARY_INSTANCE_NAME : nom de l'instance principale.
- REPLICA_NAME : nom de l'instance répliquée de reprise après sinistre.
Méthode HTTP et URL :
PATCH https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME
Corps JSON de la requête :
{ "replicationCluster": { "failoverDrReplicaName": "REPLICA_NAME" } }
Pour envoyer votre requête, développez l'une des options suivantes :
Vous devriez recevoir une réponse JSON de ce type :
Modifier la désignation de l'instance répliquée de reprise après sinistre
Si l'instance répliquée répond aux exigences, vous pouvez désigner une autre instance répliquée comme instance répliquée de reprise après sinistre. L'ancienne instance répliquée de reprise après sinistre perd la désignation d'instance répliquée de reprise après sinistre.
Console
Pour modifier l'instance répliquée de reprise après sinistre pour une instance principale, procédez comme suit :
-
Dans Google Cloud Console, accédez à la page Instances Cloud SQL.
- Recherchez et sélectionnez l'instance principale. La page Présentation de l'instance principale s'affiche.
- Dans le menu de navigation, cliquez sur Instances répliquées.
- Dans la liste des instances répliquées avec accès en lecture, recherchez l'instance répliquée interrégionale avec accès en lecture que vous souhaitez désigner comme nouvelle instance répliquée de reprise après sinistre.
- Pour l'instance répliquée, cliquez sur le bouton more_vert Actions, puis sélectionnez Désigner comme instance répliquée de reprise après sinistre.
gcloud
Pour modifier l'instance répliquée de reprise après sinistre, exécutez à nouveau la commande de désignation et spécifiez une autre instance répliquée de reprise après sinistre.
REST
Pour modifier l'instance répliquée de reprise après sinistre, envoyez à nouveau la requête API de désignation, puis spécifiez une autre instance répliquée de reprise après sinistre.
Afficher la désignation de l'instance répliquée de DR
Vous pouvez vérifier quelle instance répliquée de DR est attribuée à l'instance principale à l'aide de gcloud CLI ou de l'API Cloud SQL Admin. Vous pouvez également vérifier si une instance répliquée est une instance répliquée de reprise après sinistre désignée.
Pour savoir quelle instance répliquée de reprise après sinistre est désignée comme instance principale, suivez la procédure ci-dessous.
Console
Pour savoir quelle instance répliquée avec accès en lecture est l'instance répliquée de reprise après sinistre désignée pour une instance principale, procédez comme suit :
-
Dans Google Cloud Console, accédez à la page Instances Cloud SQL.
- Recherchez et sélectionnez l'instance principale. La page Présentation de l'instance principale s'affiche.
- Dans le menu de navigation, cliquez sur Instances répliquées.
- Dans la liste des instances répliquées avec accès en lecture, vérifiez que
MySQL disaster recovery replica
apparaît dans la colonne Type pour l'instance répliquée de reprise après sinistre désignée.
gcloud
Pour savoir quelle instance est l'instance répliquée de reprise après sinistre désignée d'une instance principale, exécutez la commande suivante :
gcloud beta sql instances describe PRIMARY_INSTANCE_NAME
Remplacez la variable suivante :
- PRIMARY_INSTANCE_NAME : nom de l'instance principale.
Le résultat de cette commande contient le champ nommé failoverDrReplica
qui identifie l'instance répliquée de reprise après sinistre désignée.
REST v1
Avant d'utiliser les données de requête, effectuez les remplacements suivants :
- PROJECT_ID : ID ou numéro de projet du projet Google Cloud contenant l'instance.
- PRIMARY_INSTANCE_NAME : nom de l'instance principale.
Méthode HTTP et URL :
GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME
Pour envoyer votre requête, développez l'une des options suivantes :
Vous devriez recevoir une réponse JSON de ce type :
REST v1beta4
Avant d'utiliser les données de requête, effectuez les remplacements suivants :
- PROJECT_ID : ID ou numéro de projet du projet Google Cloud contenant l'instance.
- PRIMARY_INSTANCE_NAME : nom de l'instance principale.
Méthode HTTP et URL :
GET https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME
Pour envoyer votre requête, développez l'une des options suivantes :
Vous devriez recevoir une réponse JSON de ce type :
Pour vérifier si une instance répliquée est une instance répliquée de reprise après sinistre, utilisez l'une des procédures suivantes.
Console
Pour vérifier si une instance répliquée est une instance répliquée de reprise après sinistre, procédez comme suit :
-
Dans Google Cloud Console, accédez à la page Instances Cloud SQL.
- Recherchez l'instance répliquée.
- Vérifiez que
MySQL disaster recovery replica
s'affiche dans la colonne Type pour l'instance répliquée de reprise après sinistre désignée.
gcloud
Pour vérifier si une instance répliquée est une instance répliquée de reprise après sinistre, exécutez la commande suivante :
gcloud beta sql instances describe REPLICA_NAME
Remplacez la variable suivante :
- REPLICA_NAME : nom de l'instance répliquée avec accès en lecture à vérifier
S'il s'agit d'une instance répliquée de DR, le résultat de la commande contient le champ drReplica=true
.
REST v1
Avant d'utiliser les données de requête, effectuez les remplacements suivants :
- PROJECT_ID : ID ou numéro de projet du projet Google Cloud contenant l'instance.
- REPLICA_NAME : nom de l'instance répliquée.
Méthode HTTP et URL :
GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME
Pour envoyer votre requête, développez l'une des options suivantes :
Vous devriez recevoir une réponse JSON de ce type :
REST v1beta4
Avant d'utiliser les données de requête, effectuez les remplacements suivants :
- PROJECT_ID : ID ou numéro de projet du projet Google Cloud contenant l'instance.
- REPLICA_NAME : nom de l'instance répliquée.
Méthode HTTP et URL :
GET https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME
Pour envoyer votre requête, développez l'une des options suivantes :
Vous devriez recevoir une réponse JSON de ce type :
Supprimer l'instance répliquée de DR
Vous pouvez effacer la désignation de l'instance répliquée de DR à partir d'une instance principale. Toutefois, si aucune instance répliquée de reprise après sinistre n'est attribuée à une instance principale, vous ne pouvez pas effectuer de commutation ni de basculement d'instance répliquée.
Console
Pour supprimer une instance répliquée de reprise après sinistre désignée d'une instance principale, procédez comme suit :
-
Dans Google Cloud Console, accédez à la page Instances Cloud SQL.
- Recherchez et sélectionnez l'instance principale. La page Présentation de l'instance principale s'affiche.
- Dans le menu de navigation, cliquez sur Instances répliquées.
- Dans la liste des instances répliquées avec accès en lecture, recherchez l'instance répliquée interrégionale avec accès en lecture que vous souhaitez supprimer.
- Pour l'instance répliquée, cliquez sur le bouton more_vert Actions, puis sélectionnez Ne plus désigner comme instance répliquée de reprise après sinistre.
- Cliquez sur Confirmer.
gcloud
Pour supprimer la désignation de l'instance répliquée de DR, exécutez la commande suivante sur l'instance principale :
gcloud beta sql instances patch PRIMARY_INSTANCE_NAME \ --clear-failover-dr-replica-name
Remplacez la variable suivante :
- PRIMARY_INSTANCE_NAME : nom de l'instance principale de laquelle vous souhaitez supprimer l'instance répliquée de reprise après sinistre désignée
REST v1
Avant d'utiliser les données de requête ci-dessous, effectuez les remplacements suivants :
- PROJECT_ID : ID ou numéro de projet du projet Google Cloud de l'instance principale et de l'instance répliquée de DR.
- PRIMARY_INSTANCE_NAME : nom de l'instance principale.
- Définissez le champ
failoverDrReplicaName
sur une chaîne vide.
Méthode HTTP et URL :
PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME
Corps JSON de la requête :
{ "replicationCluster": { "failoverDrReplicaName": "" } }
Pour envoyer votre requête, développez l'une des options suivantes :
Vous devriez recevoir une réponse JSON de ce type :
REST v1beta4
Avant d'utiliser les données de requête ci-dessous, effectuez les remplacements suivants :
- PROJECT_ID : ID ou numéro de projet du projet Google Cloud de l'instance principale et de l'instance répliquée de DR.
- PRIMARY_INSTANCE_NAME : nom de l'instance principale.
- Définissez le champ
failoverDrReplicaName
sur une chaîne vide.
Méthode HTTP et URL :
PATCH https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME
Corps JSON de la requête :
{ "replicationCluster": { "failoverDrReplicaName": "" } }
Pour envoyer votre requête, développez l'une des options suivantes :
Vous devriez recevoir une réponse JSON de ce type :
Effectuer une commutation
Une fois que vous avez désigné une instance répliquée pour la reprise après sinistre, vous pouvez effectuer l'opération de commutation. Toutefois, il est recommandé d'éviter d'effectuer l'opération de commutation dans les cas suivants :
- L'instance principale est en cours d'utilisation.
- Des opérations d'administration sont en cours, telles que la sauvegarde automatique ou l'activation ou la désactivation de la haute disponibilité.
Pour éviter ce délai, envisagez d'effectuer une commutation lorsque le volume de transactions est faible.
Une fois le basculement terminé, l'opération effectue une sauvegarde de la nouvelle instance principale (l'ancienne instance répliquée de reprise après sinistre) dès que la nouvelle instance principale est promue. Une fois cette sauvegarde terminée, la récupération à un moment précis (PITR) est entièrement activée sur la nouvelle instance principale. Cette sauvegarde peut prendre entre 5 et 15 minutes selon la taille du disque. La couverture PITR ne commence qu'une fois la sauvegarde terminée. Pour en savoir plus sur les considérations liées à l'utilisation de la récupération PITR avec la reprise après sinistre avancée, consultez la section Utiliser la récupération PITR avec la reprise après sinistre avancée.
Une fois l'opération de commutation terminée, vous remarquerez que la direction de la réplication est inversée.
Avant de commencer
Avant d'effectuer l'opération de commutation, procédez comme suit :
- Désignez une instance répliquée de reprise après sinistre. Vous ne pouvez effectuer de basculement qu'entre l'instance principale et l'instance répliquée de reprise après sinistre désignée.
- Vérifiez que l'instance principale et l'instance répliquée de DR sont en ligne.
- Effectuez une sauvegarde à la demande de l'instance principale. Cette sauvegarde est une précaution au cas où vous auriez besoin de récupérer des pannes inattendues.
Effectuer l'opération de commutation
Console
Pour effectuer l'opération de commutation, procédez comme suit :
-
Dans Google Cloud Console, accédez à la page Instances Cloud SQL.
- Recherchez l'instance répliquée de reprise après sinistre désignée de l'instance principale.
- Cliquez sur l'instance répliquée de reprise après sinistre. La page Présentation de l'instance répliquée de reprise après sinistre s'affiche.
- Cliquez sur le bouton Commutation.
- Sur la page Effectuer la commutation entre l'instance principale et l'instance répliquée avec accès en lecture désignée, saisissez le nom de l'instance principale dans le champ ID d'instance.
- Cliquez sur Commutation.
gcloud
Pour effectuer l'opération de commutation, exécutez la commande suivante :
gcloud beta sql instances switchover REPLICA_NAME [--db-timeout=TIMEOUT_DURATION ]
Remplacez les variables suivantes :
- REPLICA_NAME : nom de l'instance répliquée de reprise après sinistre désignée avec laquelle vous souhaitez que l'instance principale change de rôle.
- TIMEOUT_DURATION : (Facultatif) délai avant expiration pour permettre l'achèvement d'opérations de base de données sur l'instance.
Si vous ne spécifiez pas ce paramètre, l'opération de commutation inclut un délai d'expiration de 10 minutes.
Vous pouvez augmenter la valeur de ce délai d'expiration en spécifiant le paramètre --db-timeout
. Remplacez TIMEOUT_DURATION par une période pouvant atteindre 24 heures, y compris une notation initiale du format. Par exemple, pour 30 secondes, spécifiez 30s
Pour 24 heures, spécifiez 24h
. Vous pouvez également spécifier des unités fractionnaires de période en utilisant des nombres décimaux jusqu'à neuf chiffres. Par exemple, pour 30,5 minutes, spécifiez 30.5m
.
Si vous n'avez aucune opération en attente, vous pouvez réduire la valeur de ce délai avant expiration.
REST v1
Avant d'utiliser les données de requête ci-dessous, effectuez les remplacements suivants :
- PROJECT_ID : ID ou numéro de projet du projet Google Cloud de l'instance principale et de l'instance répliquée de DR.
- REPLICA_NAME : nom de l'instance répliquée de reprise après sinistre.
Méthode HTTP et URL :
POST https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME/switchover
Pour envoyer votre requête, développez l'une des options suivantes :
Vous devriez recevoir une réponse JSON de ce type :
REST v1beta4
Avant d'utiliser les données de requête ci-dessous, effectuez les remplacements suivants :
- PROJECT_ID : ID ou numéro de projet du projet Google Cloud de l'instance principale et de l'instance répliquée de DR.
- REPLICA_NAME : nom de l'instance répliquée de reprise après sinistre.
Méthode HTTP et URL :
POST https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME/switchover
Pour envoyer votre requête, développez l'une des options suivantes :
Vous devriez recevoir une réponse JSON de ce type :
Effectuer une reprise après sinistre en appelant un basculement d'instance répliquée
En cas de défaillance ou de sinistre, vous pouvez effectuer une reprise après sinistre en appelant une opération de basculement d'instance répliquée vers l'instance répliquée de reprise après sinistre désignée. Pour effectuer un basculement d'instance répliquée, vous devez promouvoir l'instance répliquée de reprise après sinistre désignée. Contrairement au basculement, la promotion de l'instance répliquée de DR est immédiate.
Étant donné que l'instance répliquée interrégionale de reprise après sinistre assume immédiatement le rôle d'instance principale, il est possible qu'elle ne dispose pas de toutes les données de l'ancienne instance principale en raison du délai de réplication. Pour cette raison, le basculement d'instance répliquée peut entraîner une perte de données.
Dans le cadre du processus de promotion, le basculement de l'instance répliquée effectue une sauvegarde de la nouvelle instance principale (l'ancienne instance répliquée de reprise après sinistre) juste après que l'instance répliquée de reprise après sinistre devient la nouvelle instance principale. Une fois cette sauvegarde terminée, la récupération à un moment précis (PITR) est entièrement activée sur la nouvelle instance principale. Cette sauvegarde peut prendre entre 5 et 15 minutes, en fonction de la taille du disque de la nouvelle (et de l'ancienne) instance principale. Pendant cette période de sauvegarde, la récupération PITR n'est pas disponible.
Lorsque l'ancienne instance principale est de nouveau en ligne, le processus de basculement de l'instance répliquée effectue une sauvegarde. Une fois cette sauvegarde effectuée, l'ancienne instance principale est recréée en tant qu'instance répliquée avec accès en lecture de la nouvelle instance principale. Au cours de ce processus, l'ancienne instance principale perd tous les anciens journaux de transactions PITR qui n'ont pas encore été enregistrés dans Cloud Storage. Ainsi, le basculement de l'instance répliquée ne garantit pas la conservation de tous les journaux de transactions utilisés pour la récupération PITR sur l'ancienne instance principale.
Pour en savoir plus sur les considérations liées à l'utilisation de la récupération PITR avec la reprise après sinistre avancée, consultez la page Utiliser la récupération PITR avec la reprise après sinistre avancée.
Avant de commencer
Pour pouvoir effectuer un basculement d'instance répliquée, procédez comme suit :
- Si vous ne l'avez pas déjà fait, désignez une instance répliquée de reprise après sinistre. Vous ne pouvez effectuer un basculement d'instance répliquée qu'entre l'instance principale et l'instance répliquée de reprise après sinistre désignée.
- Assurez-vous que l'instance répliquée de DR est en ligne et opérationnelle.
Effectuer l'opération de basculement d'instance répliquée
Console
Pour effectuer l'opération de basculement d'instance répliquée, procédez comme suit :
-
Dans Google Cloud Console, accédez à la page Instances Cloud SQL.
- Recherchez l'instance répliquée de reprise après sinistre désignée de l'instance principale.
- Cliquez sur l'instance répliquée de reprise après sinistre. La page Présentation de l'instance répliquée de reprise après sinistre s'affiche.
- Cliquez sur le bouton Basculement de l'instance répliquée.
- Sur la page Effectuer un basculement d'instance répliquée entre l'instance principale et l'instance répliquée avec accès en lecture désignée, saisissez le nom de l'instance principale dans le champ ID d'instance pour confirmer que vous souhaitez poursuivre l'opération.
- Pour démarrer le basculement d'instance répliquée, cliquez sur Basculement d'instance répliquée.
gcloud
Pour appeler un basculement d'instance répliquée vers l'instance répliquée de DR, exécutez la commande suivante :
gcloud beta sql instances promote-replica \ REPLICA_NAME --failover
Remplacez la variable suivante :
- REPLICA_NAME : nom de l'instance répliquée de reprise après sinistre.
REST v1
Avant d'utiliser les données de requête ci-dessous, effectuez les remplacements suivants :
- PROJECT_ID : ID ou numéro de projet du projet Google Cloud de l'instance principale et de l'instance répliquée de DR.
- REPLICA_NAME : nom de l'instance répliquée de reprise après sinistre.
- ENABLE_REPLICA_FAILOVER : défini sur
true
pour utiliser le basculement d'instance répliquée. Si vous définissez la valeur surfalse
, l'API utilise la méthode standardpromoteReplica
sans basculement d'instance répliquée.
Méthode HTTP et URL :
POST https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME/promoteReplica?failover=ENABLE_REPLICA_FAILOVER
Pour envoyer votre requête, développez l'une des options suivantes :
Vous devriez recevoir une réponse JSON de ce type :
REST v1beta4
Avant d'utiliser les données de requête ci-dessous, effectuez les remplacements suivants :
- PROJECT_ID : ID ou numéro de projet du projet Google Cloud de l'instance principale et de l'instance répliquée de DR.
- REPLICA_NAME : nom de l'instance répliquée de reprise après sinistre.
- ENABLE_REPLICA_FAILOVER : défini sur
true
pour utiliser le basculement d'instance répliquée. Si vous définissez la valeur surfalse
, l'API utilise la méthode standardpromoteReplica
sans basculement d'instance répliquée.
Méthode HTTP et URL :
POST https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME/promoteReplica?failover=ENABLE_REPLICA_FAILOVER
Pour envoyer votre requête, développez l'une des options suivantes :
Vous devriez recevoir une réponse JSON de ce type :
Vérifier l'état d'un basculement d'instance répliquée
Le basculement des instances répliquées s'effectue en deux phases. La première phase consiste à promouvoir l'instance répliquée de reprise après sinistre. La deuxième phase consiste à recréer l'ancienne instance principale en tant qu'instance répliquée avec accès en lecture.
Pour vérifier l'état du basculement de l'instance répliquée, vérifiez l'état de chaque phase.
Vérifiez l'état de la première phase.
Console
Pour vérifier si l'instance répliquée de reprise après sinistre désignée a été promue en instance autonome, procédez comme suit :
-
Dans Google Cloud Console, accédez à la page Instances Cloud SQL.
- Recherchez le nom de l'instance répliquée de reprise après sinistre que vous avez promue.
- Vérifiez que
MySQL 8.0
apparaît dans la colonne Type pour la nouvelle instance principale.
gcloud
Vous pouvez vérifier son état à l'aide de la commande suivante :gcloud sql instances describe DR_REPLICA_NAME
Remplacez la variable suivante :
- DR_REPLICA_NAME : nom de l'instance répliquée de reprise après sinistre promue
Dans le résultat, vérifiez que le champ suivant s'affiche et que l'instance répliquée est devenue une instance principale Cloud SQL autonome :
instanceType: CLOUD_SQL_INSTANCE
-
Pour vérifier l'achèvement de la deuxième phase, consultez le message
RECONFIGURE_OLD_PRIMARY
dans le journal des opérations de l'instance.L'apparence de ce message dépend du moment où l'ancienne instance principale est de nouveau en ligne, ce qui peut prendre plusieurs minutes, voire plusieurs jours en cas de sinistre.
Pour en savoir plus sur la vérification des journaux des opérations sur une instance, consultez la page Afficher les journaux d'instance.
Utiliser la récupération PITR avec la reprise après sinistre avancée
Avec le basculement et le basculement d'instance répliquée, dès que l'instance répliquée de DR est promue en instance principale, les modifications suivantes sont apportées pour assurer la sauvegarde et la récupération à un moment précis:
- La configuration des sauvegardes, y compris la planification des sauvegardes automatiques, est copiée de l'ancienne instance principale vers la nouvelle.
- Si elle est désactivée, l'option de configuration binlog est activée pour activer la récupération PITR.
- Une nouvelle sauvegarde est effectuée pour accepter la récupération PITR sur la nouvelle instance principale.
- La règle de conservation des journaux de transactions est copiée de l'ancienne instance principale vers la nouvelle.
Pour les règles de configuration de la sauvegarde et de conservation des journaux de transactions, nous vous recommandons de vérifier que les paramètres hérités de l'ancienne instance principale sont corrects pour la nouvelle instance principale.
Début de la couverture PITR
À la fin de l'opération de commutation, Cloud SQL planifie les sauvegardes automatiques et effectue la première sauvegarde de la nouvelle instance principale. Si vous souhaitez que la couverture PITR commence plus tôt, nous vous recommandons de vérifier que la première sauvegarde a réussi. L'instance principale nouvellement promue bénéficie d'une couverture PITR seulement après que la première sauvegarde automatique s'est terminée correctement.
Pour en savoir plus sur l'affichage des sauvegardes disponibles pour une instance, consultez la section Afficher la liste des sauvegardes.
Couverture PITR pour les instances lors du basculement et du basculement d'instance répliquée
Lorsqu'une instance participe à une opération de commutation ou de basculement d'instance répliquée, son passage en tant qu'instance répliquée avec accès en lecture prend un certain temps. La récupération PITR et la restauration d'une sauvegarde sont disponibles pendant la période pendant laquelle l'instance est utilisée comme réplica de lecture. Si vous souhaitez effectuer la récupération PITR à un moment antérieur à l'événement de commutation (lorsque l'instance était une instance principale), vous pouvez exécuter la commande de clonage pour cibler le moment où l'instance était une instance principale. Vous ne pouvez pas demander la récupération PITR à un moment où l'instance était une instance répliquée avec accès en lecture.
Si vous ne parvenez pas à effectuer la récupération PITR, car l'instance principale était une instance répliquée avec accès en lecture au moment en question, vous devez lancer la requête de récupération PITR sur l'instance qui servait d'instance principale à ce moment-là.
De même, vous pouvez restaurer une sauvegarde effectuée à un moment où l'instance répliquée était une instance principale. Bien que l'instance soit une instance dupliquée, la commande de restauration doit cibler une autre instance autonome et ne peut pas être restaurée sur l'instance dupliquée elle-même.
Pour déterminer l'instance à utiliser pour la requête PITR, utilisez la liste des opérations. La liste des opérations d'une instance peut vous aider à déterminer à quel moment une instance a subi des opérations de commutation ou de basculement d'instance répliquée.
Split-brain lors du basculement d'instance répliquée
Il est possible que le split-brain se produise lorsque l'instance principale continue d'accepter les écritures alors qu'un réplica est promu à l'aide du basculement de réplica. Une fois l'instance dupliquée promue, lorsque l'ancienne instance principale est à nouveau disponible, elle est recréée en tant qu'instance dupliquée de l'instance promue et une sauvegarde finale est effectuée. Cette sauvegarde peut être utilisée pour récupérer les données de split-brain qui n'ont pas été écrites sur l'instance dupliquée promue.
Supprimer des sauvegardes et des journaux de transactions sur des instances répliquées
Si une instance principale sur laquelle la récupération PITR et les sauvegardes sont activées devient une instance répliquée avec accès en lecture, la dernière sauvegarde et la dernière règle de conservation de la récupération PITR pendant sa période en tant qu'instance principale sont conservées et appliquées pendant cette période en tant qu'instance répliquée. Même si la nouvelle instance principale n'effectue pas de sauvegardes, les anciennes sauvegardes et journaux de transactions utilisés pour la récupération PITR sont supprimés sur l'instance répliquée avec accès en lecture conformément à la dernière règle configurée.
Par exemple, si l'instance est configurée pour effectuer des sauvegardes automatiques quotidiennes et conserver sept sauvegardes avec sept jours de journaux de récupération PITR, lorsque cette instance devient une instance répliquée avec accès en lecture, tout ce qui date de plus de sept jours est supprimé une fois par jour.
Si vous devez supprimer des sauvegardes plus tôt, vous pouvez supprimer les sauvegardes manuellement. Pour en savoir plus, consultez la section Supprimer une sauvegarde.
Limites
- La reprise après sinistre avancée n'est pas compatible avec les instances Cloud SQL qui utilisent Private Service Connect.
- Vous ne pouvez pas désigner une instance répliquée avec accès en lecture de l'édition Cloud SQL Enterprise Plus comme instance répliquée de reprise après sinistre si l'instance principale stocke ses journaux de transactions pour la récupération à un moment précis sur le disque. Pour vérifier où une instance stocke ses journaux pour la récupération PITR, consultez la section Vérifier l'emplacement de stockage des journaux de transactions utilisés pour la récupération à un moment précis.
- Vous ne pouvez pas désigner une instance répliquée externe comme instance répliquée de reprise après sinistre.
Résoudre les problèmes
Problème | Dépannage |
---|---|
Échec de l'opération de basculement. |
|
L'opération de basculement a échoué et l'instance principale est bloquée en mode lecture seule. | Redémarrez la base de données pour rétablir l'instance principale en mode écriture. |
L'opération de basculement est terminée, mais la console Google Cloud n'affiche pas les nouveaux rôles inversés pour les instances. | Actualisez le navigateur pour afficher la topologie mise à jour. |
Échec de l'opération de basculement d'instance répliquée. |
|
Impossible de savoir si la réplication n'a pas lieu | Connectez-vous à l'instance répliquée, puis saisissez :show slave status;
Vous pouvez également consulter l'état de réplication des instances répliquées dans le tableau de bord de surveillance de Cloud SQL. Pour en savoir plus, consultez la page Surveiller des instances Cloud SQL. |
Vous avez reçu le message d'erreur suivant :
|
Vous ne pouvez pas effectuer la récupération PITR pendant une période donnée lorsqu'une instance est basculée vers une instance répliquée. Les journaux de récupération PITR ne sont pas disponibles pour la période au cours de laquelle l'instance était une instance répliquée.
|
Vous avez reçu le message d'erreur suivant :
|
Votre instance principale n'a pas encore changé l'emplacement de stockage de ses journaux de transactions vers Cloud Storage. Vous pouvez réessayer après avoir modifié l'emplacement de stockage des journaux de transactions, ou tenter de désigner une instance répliquée de reprise après sinistre pour une autre instance principale. Pour en savoir plus sur le changement d'emplacement de stockage des journaux de transactions utilisés pour la récupération PITR, consultez la page Utiliser la récupération à un moment précis. |
Vous avez reçu le message d'erreur suivant :
|
Pour en savoir plus sur la manière de désigner une instance dupliquée de reprise après sinistre et sur la syntaxe de commande appropriée, consultez la section Désigner l'instance dupliquée de reprise après sinistre pour l'instance principale. |
Étapes suivantes
- Documentez-vous sur l'observabilité des bases de données.
- Surveiller les instances Cloud SQL