Utiliser la reprise après sinistre avancée

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 d'un réplica de reprise après sinistre, 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.

Avant de commencer

Si vous prévoyez d'utiliser Google Cloud SDK, vous devez utiliser la version 502.0.0 ou ultérieure. Pour vérifier la version de Google Cloud SDK, exécutez gcloud --version. Pour mettre à jour Google Cloud SDK, exécutez gcloud components update.

Pour installer le SDK Google Cloud, consultez la page Installer gcloud CLI.

Conditions requises pour l'instance principale

L'instance principale doit être une instance Cloud SQL Enterprise Plus et disposer d'un réplica de reprise après sinistre désigné.

Vous devez activer la récupération à un moment précis (PITR) sur l'instance principale. Pour activer la récupération PITR, consultez la page Utiliser la récupération à un moment précis (PITR).

Si vous créez votre instance Cloud SQL avec un point de terminaison d'écriture DNS (Preview), votre instance principale doit avoir la même configuration SSL que le réplica de reprise après sinistre désigné avant d'appeler l'opération de commutation ou de commutation d'instance répliquée. Par exemple, si vous configurez votre réplication de reprise après sinistre pour appliquer le chiffrement SSL, mais que l'instance principale autorise les connexions non chiffrées, les clients ne pourront pas se connecter à la nouvelle instance principale une fois l'opération de commutation ou de basculement terminée.

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 la même version de base de données que l'instance principale, exécutant PostgreSQL 12, 13, 14, 15 ou 16

  • 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)

  • Si le réplicat est configuré avec un indicateur qui exige que sa valeur soit supérieure ou égale à celle de l'instance principale, l'indicateur doit être configuré avec une valeur égale à celle de l'instance principale.

  • L'indicateur cloudsql.logical_decoding ne peut pas être configuré. Aucun emplacement logique ni aucune réplication logique ne peut être configuré.

  • 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

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

    Accéder à la page Instances Cloud SQL

  2. Recherchez l'instance principale.
  3. Dans la colonne Actions, cliquez sur le menu Autres actions.
  4. Sélectionnez Créer une instance dupliquée avec accès en lecture.
  5. Dans le champ ID d'instance, saisissez un nom pour l'instance répliquée de DR.
  6. Dans le champ Version de la base de données, la même version majeure de l'instance principale est sélectionnée pour vous.
  7. 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.
  8. 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.
  9. Pour Formes de machines, sélectionnez le même type de machine que votre instance principale.
  10. Pour le champ Options, configurez les options requises pour votre base de données.
  11. 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 POSTGRES_16.

    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 de la base de données de l'instance principale, par exemple POSTGRES_16. La version de la base de données doit être identique 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 de la base de données de l'instance principale, par exemple POSTGRES_16. La version de la base de données doit être identique 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 :

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

    Accéder à la page Instances Cloud SQL

  2. Recherchez et sélectionnez l'instance principale. La page Présentation de l'instance principale s'affiche.
  3. Dans le menu de navigation, cliquez sur Instances répliquées.
  4. 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.
  5. 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.
  6. Cliquez sur Confirmer.

gcloud

Pour désigner une instance répliquée de DR comme instance principale, exécutez la commande suivante :

gcloud 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/sql/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 :

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

    Accéder à la page Instances Cloud SQL

  2. Recherchez et sélectionnez l'instance principale. La page Présentation de l'instance principale s'affiche.
  3. Dans le menu de navigation, cliquez sur Instances répliquées.
  4. 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.
  5. 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 :

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

    Accéder à la page Instances Cloud SQL

  2. Recherchez et sélectionnez l'instance principale. La page Présentation de l'instance principale s'affiche.
  3. Dans le menu de navigation, cliquez sur Instances répliquées.
  4. Dans la liste des instances répliquées avec accès en lecture, vérifiez que PostgreSQL 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 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 :

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

    Accéder à la page Instances Cloud SQL

  2. Recherchez l'instance répliquée.
  3. Vérifiez que PostgreSQL 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 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/sql/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 :

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

    Accéder à la page Instances Cloud SQL

  2. Recherchez et sélectionnez l'instance principale. La page Présentation de l'instance principale s'affiche.
  3. Dans le menu de navigation, cliquez sur Instances répliquées.
  4. 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.
  5. 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.
  6. 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 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/sql/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.

Une fois votre ancienne instance principale reconfigurée en tant qu'instance répliquée avec accès en lecture, le point de terminaison d'écriture DNS, qui était auparavant résolu vers l'ancienne instance principale, est résolu vers la nouvelle instance principale.

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.
  • Assurez-vous que la récupération PITR est activée sur l'instance principale. Pour activer la récupération PITR, consultez la page Utiliser la récupération à un moment précis (PITR).
  • Si vous utilisez un point de terminaison d'écriture DNS, vérifiez que la configuration SSL de l'instance principale et du réplica DR est identique. Par exemple, si l'instance répliquée de reprise après sinistre est configurée pour appliquer le chiffrement SSL, mais que l'instance principale autorise les connexions non chiffrées, les clients ne pourront pas se connecter à la nouvelle instance principale une fois l'opération de commutation terminée.
  • 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 :

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

    Accéder à la page Instances Cloud SQL

  2. Recherchez l'instance répliquée de reprise après sinistre désignée de l'instance principale.
  3. 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.
  4. Cliquez sur le bouton Commutation.
  5. Sur la page Effectuer la commutation entre l'instance principale et l'instance répliquée de DR, saisissez le nom de l'instance principale dans le champ ID d'instance.
  6. Cliquez sur Commutation.

gcloud

Pour effectuer l'opération de commutation, exécutez la commande suivante :

gcloud 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/sql/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 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.

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.

Une fois que vous avez appelé l'opération de basculement d'instance répliquée, le point de terminaison d'écriture DNS, qui pointait auparavant vers l'ancienne instance principale, pointe vers la nouvelle instance principale.

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 :

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

    Accéder à la page Instances Cloud SQL

  2. 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.
  3. Cliquez sur le bouton Basculement de l'instance répliquée.
  4. Sur la page Effectuer un basculement d'instance répliquée entre l'instance principale et l'instance répliquée de reprise après sinistre, saisissez le nom de l'instance principale dans le champ ID d'instance pour confirmer que vous souhaitez poursuivre l'opération.
  5. 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 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 sur false, l'API utilise la méthode standard promoteReplica 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 sur false, l'API utilise la méthode standard promoteReplica sans basculement d'instance répliquée.

Méthode HTTP et URL : 

POST https://sqladmin.googleapis.com/sql/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.

  1. Vérifiez l'état de la première phase.

    Console

    Pour vérifier si l'instance répliquée de reprise après sinistre a été promue en instance autonome, procédez comme suit:

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

      Accéder à la page Instances Cloud SQL

    2. Recherchez le nom de l'instance répliquée de reprise après sinistre que vous avez promue.
    3. Vérifiez que PostgreSQL VERSION 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

  2. 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.

  • 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 où l'instance est une instance répliquée avec accès en lecture et une instance principale.

Vous pouvez effectuer la récupération PITR à un moment antérieur à la commutation lorsque l'instance était une instance principale. Pour les opérations de commutation et de basculement d'instance répliquée, Cloud SQL lance une sauvegarde du mieux possible pour la nouvelle instance principale dès qu'elle est promue. La récupération PITR n'est activée sur l'instance promue qu'une fois cette sauvegarde terminée. Cette sauvegarde peut prendre entre 5 et 15 minutes, en fonction de la taille du disque.

Split-brain lors du basculement d'instance répliquée

Il est possible que la situation de split-brain se produise lorsque l'instance principale continue d'accepter les écritures alors qu'un réplica est promu à l'aide d'un basculement de réplica. Une fois le réplica promu, lorsque l'ancienne instance principale redevient disponible, elle est recréée en tant que réplica de l'instance promue et une sauvegarde finale est effectuée. Cette sauvegarde peut être utilisée pour récupérer toutes les données de cerveau divisé qui n'ont pas été écrites dans la réplique 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. La reprise après sinistre avancée est compatible avec l'accès aux services privés.

  • 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.

  • Terraform n'est pas compatible avec les opérations de commutation ou de basculement d'instance répliquée.

  • La reprise après sinistre avancée n'est pas compatible avec PostgreSQL 17.

Résoudre les problèmes

Problème Dépannage
Échec de l'opération de basculement.
  • Vérifiez le volume de transactions sur la base de données. Si le volume de la transaction est élevé, l'opération peut expirer. Envisagez de relancer l'opération lorsque la charge de transaction est plus faible.
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.
  • Si le basculement vers l'instance répliquée de reprise après sinistre a échoué, convertissez plutôt une instance répliquée avec accès en lecture standard (non DR).

Étape suivante