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. Pour Cloud SQL pour SQL Server, l'instance répliquée de reprise après sinistre est une instance répliquée en cascade.
• 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.

Créer une instance répliquée de reprise après sinistre

Avant d'utiliser la reprise après sinistre avancée, créez une instance répliquée pour cascade de l'instance principale dans une région différente de celle de l'instance principale.

Effectuer une commutation

Une fois que vous avez créé 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 :

• Si vous ne l'avez pas déjà fait, créez une instance répliquée de reprise après sinistre.
• Vérifiez que l'instance principale et l'instance répliquée de DR sont en ligne.
• 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

gcloud sql instances switchover REPLICA_NAME

POST https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME/switchover

curl -X POST \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d "" \
     "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME/switchover"

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method POST `
    -Headers $headers `
    -Uri "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME/switchover" | Select-Object -Expand Content

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2024-04-01T22:43:37.981Z",
  "operationType": "SWITCHOVER",
  "name": "OPERATION_ID",
  "targetId": "REPLICA_ID",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

POST https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME/switchover

curl -X POST \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d "" \
     "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME/switchover"

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method POST `
    -Headers $headers `
    -Uri "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME/switchover" | Select-Object -Expand Content

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2024-04-01T22:43:37.981Z",
  "operationType": "SWITCHOVER",
  "name": "OPERATION_ID",
  "targetId": "REPLICA_ID",
  "selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

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. 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, créez une instance répliquée de reprise après sinistre.
• 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

gcloud sql instances promote-replica \
   REPLICA_NAME --failover

POST https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME/promoteReplica?failover=ENABLE_REPLICA_FAILOVER

curl -X POST \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d "" \
     "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME/promoteReplica?failover=ENABLE_REPLICA_FAILOVER"

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method POST `
    -Headers $headers `
    -Uri "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME/promoteReplica?failover=ENABLE_REPLICA_FAILOVER" | Select-Object -Expand Content

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/REPLICA_NAME",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2020-01-21T22:43:37.981Z",
  "operationType": "PROMOTE_REPLICA",
  "name": "OPERATION_ID",
  "targetId": "REPLICA_NAME",
  "selfLink": "https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

POST https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME/promoteReplica?failover=ENABLE_REPLICA_FAILOVER

curl -X POST \
     -H "Authorization: Bearer $(gcloud auth print-access-token)" \
     -H "Content-Type: application/json; charset=utf-8" \
     -d "" \
     "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME/promoteReplica?failover=ENABLE_REPLICA_FAILOVER"

$cred = gcloud auth print-access-token
$headers = @{ "Authorization" = "Bearer $cred" }

Invoke-WebRequest `
    -Method POST `
    -Headers $headers `
    -Uri "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME/promoteReplica?failover=ENABLE_REPLICA_FAILOVER" | Select-Object -Expand Content

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME",
  "status": "PENDING",
  "user": "user@example.com",
  "insertTime": "2024-04-01T22:43:37.981Z",
  "operationType": "PROMOTE_REPLICA",
  "name": "OPERATION_ID",
  "targetId": "REPLICA_NAME",
  "selfLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

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 SQL Server 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 scission cérébrale 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.

• Vous ne pouvez pas utiliser la console Google Cloud pour effectuer des opérations de basculement ou de failover de réplication.

Résoudre les problèmes

Étape suivante

• Affichez tous les services Google Cloud disponibles dans le monde entier.
• Documentez-vous sur l'observabilité des bases de données.
• Surveiller les instances Cloud SQL