Utilizza il ripristino di emergenza (RE) avanzato

Questa pagina descrive come utilizzare il recupero di emergenza (DR) avanzato. Il ripristino di emergenza avanzato offre due funzionalità principali:

  • Il failover della replica consente di eseguire immediatamente il failover dell'istanza principale sulla replica di DR in caso di errore della regione.
  • Switchover consente di invertire i ruoli dell'istanza principale e di una replica DR senza perdita di dati. Puoi utilizzare il cambio di ruolo per ripristinare uno stato di deployment originale dopo il failover della replica oppure puoi utilizzare il cambio di ruolo per testare il DR.

Il ripristino di emergenza avanzato è supportato solo sulle istanze della versione Cloud SQL Enterprise Plus.

Prima di iniziare

Se prevedi di utilizzare Google Cloud SDK, devi utilizzare la versione 502.0.0 o successiva. Per controllare la versione di Google Cloud SDK, esegui gcloud --version. Per aggiornare Google Cloud SDK, esegui gcloud components update.

Per installare Google Cloud SDK, vedi Installa gcloud CLI.

Designa una replica RE

Per eseguire il DR avanzato, devi prima designare una replica DR cross-regione.

Requisiti dell'istanza principale

L'istanza primaria deve essere un'istanza Cloud SQL Enterprise Plus e avere una replica di ripristino di emergenza designata.

Devi abilitare il recupero point-in-time (PITR) sull'istanza primaria. Per abilitare PITR, consulta Utilizzare il recupero point-in-time (PITR).

Se crei l'istanza Cloud SQL con un endpoint di scrittura DNS, l'istanza primaria deve avere la stessa configurazione SSL della replica di DR designata prima di richiamare l'operazione di switchover o failover della replica. Ad esempio, se configuri la replica di DR per imporre la crittografia SSL, ma l'istanza principale consente connessioni non criptate, i client non potranno connettersi alla nuova istanza principale dopo il completamento dell'operazione di switchover o failover.

Requisiti della replica RE

La replica di lettura di DR designata deve soddisfare i seguenti requisiti:

  • Deve essere un'istanza della versione Cloud SQL Enterprise Plus
  • Deve essere la stessa versione del database dell'istanza principale, in esecuzione su PostgreSQL 12 o versioni successive

  • Deve trovarsi in una regione separata dall'istanza principale

  • Deve essere una replica di lettura diretta, non una replica a cascata

  • Se configurato con un flag che richiede che la replica abbia un valore maggiore o uguale a quello dell'istanza principale, il flag deve essere configurato con un valore uguale a quello dell'istanza principale. Tieni presente che, a seconda del tipo di macchina (livello) e delle dimensioni dell'istanza della replica di DR, i valori predefiniti possono essere diversi anche se non li hai impostati in modo esplicito. Questi flag sono i seguenti:

    • max_connections
    • max_worker_processes
    • max_wal_senders
    • max_prepared_transactions
    • max_parallel_workers
    • max_locks_per_transaction
    • max_parallel_maintenance_workers
    • max_parallel_workers_per_gather

  • Non può avere il flag cloudsql.logical_decoding configurato; non può avere slot logici o replica logica configurati

  • Deve archiviare i log delle transazioni utilizzati per il PITR in Cloud Storage

  • Non può essere una replica esterna

Consigli per le repliche RE

Questa sezione fornisce consigli per la replica di DR. I seguenti consigli possono aiutarti a evitare problemi di prestazioni nella tua implementazione:

  • Utilizza le stesse dimensioni del disco dell'istanza primaria o abilita l'aumento automatico.
  • Utilizza una configurazione HA coerente. Se abiliti l'alta affidabilità nell'istanza principale, abilita l'alta affidabilità anche nella replica di DR.
  • Utilizza una configurazione coerente della cache dei dati. Se abiliti la cache dei dati sull'istanza principale, abilita la cache dei dati anche sulla replica DR.
  • Configura i flag di database appropriati per la replica di DR prima e dopo qualsiasi operazione di failover della replica o di switchover.
  • Utilizza lo stesso tipo di macchina (livello) e le stesse dimensioni sia per l'istanza principale sia per la replica di ripristino di emergenza.

Crea una replica per soddisfare i requisiti della replica di DR

Se l'istanza principale non ha già una replica di lettura tra regioni che soddisfi i requisiti della replica di DR, creane una.

Console

  1. Nella console Google Cloud , vai alla pagina Istanze Cloud SQL.

    Vai a Istanze Cloud SQL

  2. Trova l'istanza principale.
  3. Nella colonna Azioni, fai clic sul menu Altre azioni.
  4. Seleziona Crea replica di lettura.
  5. Nel campo ID istanza, inserisci un nome per la replica DR.
  6. Nel campo Versione del database, viene selezionata la stessa versione principale dell'istanza principale.
  7. Nella sezione Scegli una regione e la disponibilità per zona della pagina, segui questi passaggi:
    • Seleziona una regione _diversa_ da quella dell'istanza principale.
    • Facoltativo. Seleziona Più zone per la replica di DR.
    • Facoltativo. Seleziona le zone principali e secondarie per la replica di DR.
  8. Nella sezione Personalizza la tua istanza della pagina, puoi aggiornare le impostazioni per la replica di DR. Per maggiori dettagli su ciascuna impostazione, consulta la pagina Informazioni sulle impostazioni per le istanze.
  9. Per Forme macchina, seleziona lo stesso tipo di macchina dell'istanza principale.
  10. Per Flag, configura tutti i flag richiesti per il tuo database.
  11. Fai clic su Crea replica.

Cloud SQL crea un backup dell'istanza principale e crea la replica. Tornerai alla pagina dell'istanza primaria.

gcloud

Per creare una replica che soddisfi i requisiti di una replica di DR, esegui questo comando:

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"

Sostituisci le seguenti variabili:

  • REPLICA_NAME: il nome della replica di DR.
  • PRIMARY_INSTANCE_NAME: il nome dell'istanza primaria.
  • REPLICA_REGION_NAME: specifica una regione diversa da quella dell'istanza primaria.
  • DATABASE_VERSION: specifica la stringa di versione che corrisponde alla versione principale e secondaria del database dell'istanza principale, ad esempio POSTGRES_16.

    Le versioni principali e secondarie del database devono essere le stesse sia per la replica primaria che per la replica di ripristino di emergenza.

  • MACHINE_TYPE: specifica lo stesso tipo di macchina dell'istanza principale. Ti consigliamo di scegliere un tipo di macchina che corrisponda a quello dell'istanza principale.
  • AVAILABILITY_TYPE: se l'istanza principale è configurata per l'alta disponibilità, ti consigliamo di specificare REGIONAL per abilitare l'alta disponibilità.
  • EDITION: specifica ENTERPRISE_PLUS.

Terraform

Per creare una replica di ripristino di emergenza, utilizza una risorsa Terraform.

resource "google_sql_database_instance" "original-primary" {
  name   = "postgres-original-primary-instance"
  region = "us-east1"
  # Specify a database version that supports Cloud SQL Enterprise Plus edition.
  database_version = "POSTGRES_12"
  instance_type    = "CLOUD_SQL_INSTANCE"

  settings {
    # Specify a tier that supports Cloud SQL Enterprise Plus edition.
    tier    = "db-perf-optimized-N-2"
    edition = "ENTERPRISE_PLUS"
    backup_configuration {
      # You must enable automated backups and point-in-time-recovery (PITR).
      enabled                        = true
      point_in_time_recovery_enabled = true
    }
  }
  # Set `deletion_protection` to true to ensure that one can't accidentally
  # delete this instance by use of Terraform whereas
  # `deletion_protection_enabled` flag protects this instance at the Google Cloud level.
  deletion_protection = false
}

resource "google_sql_database_instance" "dr-replica" {
  name = "postgres-dr-replica-instance"
  # DR replica must be in a different region than the region of the primary instance.
  region = "us-west2"
  # DR replica must be the same database version as the primary instance.
  database_version = "POSTGRES_12"
  instance_type    = "READ_REPLICA_INSTANCE"
  # Specify the primary instance as the master instance.
  master_instance_name = google_sql_database_instance.original-primary.name

  settings {
    # DR replica must be in the same tier as your primary instance and support Enterprise Plus edition.
    tier    = "db-perf-optimized-N-2"
    edition = "ENTERPRISE_PLUS"
  }

  # Set `deletion_protection` to true to ensure that one can't accidentally
  # delete this instance by use of Terraform whereas
  # `deletion_protection_enabled` flag protects this instance at the Google Cloud level.
  deletion_protection = false
}

REST v1

Prima di utilizzare i dati della richiesta, apporta le sostituzioni seguenti:

  • PRIMARY_INSTANCE_NAME: il nome dell'istanza primaria.
  • PROJECT_ID: l'ID o il numero di progetto del progetto Google Cloud dell'istanza primaria e della replica di DR.
  • Stringa di versione DATABASE_VERSION: che corrisponde alla versione del database dell'istanza principale, ad esempio POSTGRES_16. La versione del database deve essere la stessa sia per la replica primaria che per quella di DR.
  • REPLICA_NAME: il nome dell'istanza di replica di ripristino di emergenza che stai creando.
  • REPLICA_REGION: la regione dell'istanza di replica DR. La regione di replica deve essere diversa dalla regione dell'istanza primaria.
  • MACHINE_TYPE: specifica lo stesso tipo di macchina dell'istanza principale. Ti consigliamo di selezionare lo stesso tipo di macchina dell'istanza principale.
  • AVAILABILITY_TYPE: se l'istanza primaria è configurata per l'alta disponibilità, ti consigliamo di specificare REGIONAL per abilitare l'alta disponibilità.

Metodo HTTP e URL: 

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

Corpo JSON della richiesta: 

{
  "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",
  }
}

Per inviare la richiesta, espandi una di queste opzioni:

Dovresti ricevere una risposta JSON simile alla seguente:

REST v1beta4

Prima di utilizzare i dati della richiesta, apporta le sostituzioni seguenti:

  • PRIMARY_INSTANCE_NAME: il nome dell'istanza primaria.
  • PROJECT_ID: l'ID o il numero di progetto del progetto Google Cloud dell'istanza primaria e della replica di DR.
  • Stringa di versione DATABASE_VERSION: che corrisponde alla versione del database dell'istanza principale, ad esempio POSTGRES_16. La versione del database deve essere la stessa sia per la replica primaria che per quella di DR.
  • REPLICA_NAME: il nome dell'istanza di replica di ripristino di emergenza che stai creando.
  • REPLICA_REGION: la regione dell'istanza di replica DR. La regione di replica deve essere diversa dalla regione dell'istanza primaria.
  • MACHINE_TYPE: specifica lo stesso tipo di macchina dell'istanza principale. Ti consigliamo di impostare le dimensioni del disco in modo che corrispondano a quelle dell'istanza primaria.
  • AVAILABILITY_TYPE: se l'istanza primaria è configurata per l'alta disponibilità, ti consigliamo di specificare REGIONAL per abilitare l'alta disponibilità.

Metodo HTTP e URL: 

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

Corpo JSON della richiesta: 

{
  "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",
  }
}

Per inviare la richiesta, espandi una di queste opzioni:

Dovresti ricevere una risposta JSON simile alla seguente:

Designa la replica RE per l'istanza principale

Le seguenti procedure descrivono come designare una delle repliche multiregionali di un'istanza primaria come replica DR per il cambio di ruolo o il failover della replica.

Console

Per designare una replica di ripristino di emergenza per un'istanza primaria:

  1. Nella console Google Cloud , vai alla pagina Istanze Cloud SQL.

    Vai a Istanze Cloud SQL

  2. Trova e seleziona l'istanza principale. Viene visualizzata la pagina Panoramica dell'istanza principale.
  3. Nel menu di navigazione, fai clic su Repliche.
  4. Nell'elenco delle repliche di lettura, trova la replica di lettura tra regioni che vuoi designare come replica di ripristino di emergenza.
  5. Per la replica, fai clic sul pulsante more_vert Azioni e seleziona Designa come replica di ripristino di emergenza.
  6. Fai clic su Conferma.

gcloud

Per designare una replica di ripristino di emergenza per un'istanza primaria, utilizza il seguente comando:

gcloud sql instances patch PRIMARY_INSTANCE_NAME \
   --failover-dr-replica-name=REPLICA_NAME

Sostituisci le seguenti variabili:

  • PRIMARY_INSTANCE_NAME: il nome dell'istanza primaria.
  • REPLICA_NAME: il nome della replica di DR.

Terraform

Per designare una replica di ripristino di emergenza per un'istanza primaria, utilizza una risorsa Terraform.

data "google_project" "default" {
}

resource "google_sql_database_instance" "original-primary" {
  name             = "postgres-original-primary-instance"
  region           = "us-east1"
  database_version = "POSTGRES_12"
  instance_type    = "CLOUD_SQL_INSTANCE"

  replication_cluster {
    # Designate the DR replica.
    # The format for setting the DR replica is `project-id:dr-replica-name`.
    failover_dr_replica_name = "${data.google_project.default.project_id}:postgres-dr-replica-instance"
  }

  settings {
    tier    = "db-perf-optimized-N-2"
    edition = "ENTERPRISE_PLUS"
    backup_configuration {
      enabled                        = true
      point_in_time_recovery_enabled = true
    }
  }
  # Set `deletion_protection` to true to ensure that one can't accidentally
  # delete this instance by use of Terraform whereas
  # `deletion_protection_enabled` flag protects this instance at the Google Cloud level.
  deletion_protection = false
  # Optional. Add more settings.
}

resource "google_sql_database_instance" "dr-replica" {
  name                 = "postgres-dr-replica-instance"
  region               = "us-west2"
  database_version     = "POSTGRES_12"
  instance_type        = "READ_REPLICA_INSTANCE"
  master_instance_name = google_sql_database_instance.original-primary.name

  settings {
    tier    = "db-perf-optimized-N-2"
    edition = "ENTERPRISE_PLUS"
  }

  # Set `deletion_protection` to true to ensure that one can't accidentally
  # delete this instance by use of Terraform whereas
  # `deletion_protection_enabled` flag protects this instance at the Google Cloud level.
  deletion_protection = false
  # Optional. Add more settings.
}

REST v1

Prima di utilizzare i dati della richiesta, apporta le sostituzioni seguenti:

  • PRIMARY_INSTANCE_NAME: il nome dell'istanza primaria.
  • REPLICA_NAME: il nome della replica di DR.

Metodo HTTP e URL: 

PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME

Corpo JSON della richiesta: 

{
  "replicationCluster": {
     "failoverDrReplicaName": "REPLICA_NAME"
   }
}

Per inviare la richiesta, espandi una di queste opzioni:

Dovresti ricevere una risposta JSON simile alla seguente:

REST v1beta4

Prima di utilizzare i dati della richiesta, apporta le sostituzioni seguenti:

  • PRIMARY_INSTANCE_NAME: il nome dell'istanza primaria.
  • REPLICA_NAME: il nome della replica di DR.

Metodo HTTP e URL: 

PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME

Corpo JSON della richiesta: 

{
  "replicationCluster": {
     "failoverDrReplicaName": "REPLICA_NAME"
   }
}

Per inviare la richiesta, espandi una di queste opzioni:

Dovresti ricevere una risposta JSON simile alla seguente:

Modificare la designazione della replica RE

Se la replica soddisfa i requisiti, puoi designare una replica diversa come replica DR. La vecchia replica RE perde la designazione di replica RE.

Console

Per modificare la replica di ripristino di emergenza per un'istanza principale:

  1. Nella console Google Cloud , vai alla pagina Istanze Cloud SQL.

    Vai a Istanze Cloud SQL

  2. Trova e seleziona l'istanza principale. Viene visualizzata la pagina Panoramica dell'istanza principale.
  3. Nel menu di navigazione, fai clic su Repliche.
  4. Nell'elenco delle repliche di lettura, trova la replica di lettura tra regioni che vuoi designare come nuova replica di ripristino di emergenza.
  5. Per la replica, fai clic sul pulsante more_vert Azioni e seleziona Designa come replica di ripristino di emergenza.

gcloud

Per modificare la replica di DR, esegui di nuovo il comando designate e specifica una replica di DR diversa.

REST

Per modificare la replica di DR, invia di nuovo la richiesta API designate e specifica una replica di DR diversa.

Visualizzare la designazione della replica RE

Puoi controllare quale replica di ripristino di emergenza è assegnata all'istanza primaria utilizzando gcloud CLI o l'API Cloud SQL Admin. Puoi anche verificare se una replica è una replica di DR designata.

Per scoprire quale replica di DR è designata per un'istanza primaria, utilizza la seguente procedura.

Console

Per scoprire quale replica di lettura è la replica di ripristino di emergenza designata per un'istanza principale:

  1. Nella console Google Cloud , vai alla pagina Istanze Cloud SQL.

    Vai a Istanze Cloud SQL

  2. Trova e seleziona l'istanza principale. Viene visualizzata la pagina Panoramica dell'istanza principale.
  3. Nel menu di navigazione, fai clic su Repliche.
  4. Nell'elenco delle repliche di lettura, verifica che PostgreSQL disaster recovery replica venga visualizzato nella colonna Tipo per la replica di DR designata.

gcloud

Per scoprire quale istanza è la replica di DR designata di un'istanza primaria, utilizza il seguente comando:

gcloud sql instances describe PRIMARY_INSTANCE_NAME

Sostituisci la seguente variabile:

  • PRIMARY_INSTANCE_NAME: il nome dell'istanza primaria

L'output di questo comando contiene il campo denominato failoverDrReplica, che identifica la replica di DR designata.

REST v1

Prima di utilizzare i dati della richiesta, apporta le sostituzioni seguenti:

  • PROJECT_ID: l'ID o il numero di progetto del Google Cloud progetto che contiene l'istanza.
  • PRIMARY_INSTANCE_NAME: il nome dell'istanza primaria.

Metodo HTTP e URL: 

GET https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME

Per inviare la richiesta, espandi una di queste opzioni:

Dovresti ricevere una risposta JSON simile alla seguente:

REST v1beta4

Prima di utilizzare i dati della richiesta, apporta le sostituzioni seguenti:

  • PROJECT_ID: l'ID o il numero di progetto del Google Cloud progetto che contiene l'istanza.
  • PRIMARY_INSTANCE_NAME: il nome dell'istanza primaria.

Metodo HTTP e URL: 

GET https://sqladmin.googleapis.com/v1beta4/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME

Per inviare la richiesta, espandi una di queste opzioni:

Dovresti ricevere una risposta JSON simile alla seguente:

Per verificare se una replica è una replica di DR, utilizza una delle seguenti procedure.

Console

Per verificare se un'istanza di replica è una replica di DR, segui questi passaggi:

  1. Nella console Google Cloud , vai alla pagina Istanze Cloud SQL.

    Vai a Istanze Cloud SQL

  2. Trova l'istanza replica.
  3. Verifica che PostgreSQL disaster recovery replica venga visualizzato nella colonna Tipo per la replica di DR designata.

gcloud

Per verificare se un'istanza di replica è una replica di DR, esegui questo comando:

gcloud sql instances describe REPLICA_NAME

Sostituisci la seguente variabile:

  • REPLICA_NAME: il nome della replica di lettura che vuoi controllare

Se la replica è una replica di ripristino di emergenza, l'output del comando contiene il campo drReplica=true.

REST v1

Prima di utilizzare i dati della richiesta, apporta le sostituzioni seguenti:

  • PROJECT_ID: l'ID o il numero di progetto del Google Cloud progetto che contiene l'istanza.
  • REPLICA_NAME: il nome della replica.

Metodo HTTP e URL: 

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

Per inviare la richiesta, espandi una di queste opzioni:

Dovresti ricevere una risposta JSON simile alla seguente:

REST v1beta4

Prima di utilizzare i dati della richiesta, apporta le sostituzioni seguenti:

  • PROJECT_ID: l'ID o il numero di progetto del Google Cloud progetto che contiene l'istanza.
  • REPLICA_NAME: il nome della replica.

Metodo HTTP e URL: 

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

Per inviare la richiesta, espandi una di queste opzioni:

Dovresti ricevere una risposta JSON simile alla seguente:

Rimuovi la replica RE

Puoi cancellare la designazione della replica di ripristino di emergenza da un'istanza principale. Tuttavia, se a un'istanza principale non è assegnata alcuna replica di ripristino di emergenza, non puoi eseguire il cambio o il failover della replica.

Console

Per rimuovere una replica di recupero di emergenza designata da un'istanza primaria:

  1. Nella console Google Cloud , vai alla pagina Istanze Cloud SQL.

    Vai a Istanze Cloud SQL

  2. Trova e seleziona l'istanza principale. Viene visualizzata la pagina Panoramica dell'istanza principale.
  3. Nel menu di navigazione, fai clic su Repliche.
  4. Nell'elenco delle repliche di lettura, individua la replica di lettura tra regioni che vuoi rimuovere.
  5. Per la replica, fai clic sul pulsante more_vert Azioni e seleziona Rimuovi come replica di ripristino di emergenza.
  6. Fai clic su Conferma.

gcloud

Per rimuovere la designazione di replica di ripristino di emergenza, esegui questo comando sull'istanza principale:

gcloud sql instances patch PRIMARY_INSTANCE_NAME \
  --clear-failover-dr-replica-name

Sostituisci la seguente variabile:

  • PRIMARY_INSTANCE_NAME: il nome dell'istanza primaria da cui vuoi rimuovere la replica RE designata

REST v1

Prima di utilizzare i dati della richiesta, apporta le sostituzioni seguenti:

  • PROJECT_ID: l'ID o il numero di progetto del progetto Google Cloud dell'istanza primaria e della replica di DR.
  • PRIMARY_INSTANCE_NAME: il nome dell'istanza primaria.
  • Imposta il campo failoverDrReplicaName su una stringa vuota.

Metodo HTTP e URL: 

PATCH https://sqladmin.googleapis.com/v1/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME

Corpo JSON della richiesta: 

{
  "replicationCluster": {
     "failoverDrReplicaName": ""
   }
}

Per inviare la richiesta, espandi una di queste opzioni:

Dovresti ricevere una risposta JSON simile alla seguente:

REST v1beta4

Prima di utilizzare i dati della richiesta, apporta le sostituzioni seguenti:

  • PROJECT_ID: l'ID o il numero di progetto del progetto Google Cloud dell'istanza primaria e della replica di DR.
  • PRIMARY_INSTANCE_NAME: il nome dell'istanza primaria.
  • Imposta il campo failoverDrReplicaName su una stringa vuota.

Metodo HTTP e URL: 

PATCH https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/PRIMARY_INSTANCE_NAME

Corpo JSON della richiesta: 

{
  "replicationCluster": {
     "failoverDrReplicaName": ""
   }
}

Per inviare la richiesta, espandi una di queste opzioni:

Dovresti ricevere una risposta JSON simile alla seguente:

Eseguire un cambio

Dopo aver designato una replica di ripristino di emergenza, puoi eseguire l'operazione di switchover. Tuttavia, come best practice, evita di eseguire l'operazione di trasferimento nelle seguenti circostanze:

  • L'istanza principale è in uso attivo.
  • Sono in corso operazioni di amministrazione, come il backup automatico o l'attivazione o la disattivazione dell'alta disponibilità (HA).

Per evitare un timeout, valuta la possibilità di eseguire il cambio quando il volume delle transazioni è basso.

Al termine dello switchover, l'operazione esegue un backup della nuova istanza principale (l'ex replica di DR) non appena viene eseguita la promozione della nuova istanza principale. Una volta completato il backup, il recupero point-in-time (PITR) viene abilitato completamente nella nuova istanza principale. Il completamento di questo backup può richiedere da 5 a 15 minuti, a seconda delle dimensioni del disco. La copertura PITR inizia solo dopo il completamento di questo backup. Per saperne di più sulle considerazioni relative all'utilizzo di PITR con il ripristino di emergenza avanzato, consulta Utilizzare PITR con il ripristino di emergenza avanzato.

Al termine dell'operazione di switchover, noterai che la direzione della replica è invertita.

Dopo che la vecchia istanza principale è stata riconfigurata come replica di lettura, l'endpoint di scrittura DNS, che in precedenza veniva risolto nella vecchia istanza principale, viene risolto nella nuova istanza principale.

Se configuri la connettività in uscita di Private Service Connect nella replica di disaster recovery (DR), la connettività in uscita continua a funzionare nella nuova istanza primaria creata quando la replica di DR viene promossa a istanza primaria dopo un'operazione di switchover. Se non configuri la connettività in uscita sulla replica di ripristino di emergenza (DR), devi abilitare la connettività in uscita di Private Service Connect sulla nuova istanza primaria affinché il servizio continui a funzionare dopo le operazioni di switchover.

Prima di iniziare

Prima di eseguire l'operazione di switchover:

  • Designa una replica RE. Puoi eseguire un cambio solo tra l'istanza principale e la replica di DR designata.
  • Verifica che l'istanza principale e la replica DR siano online.
  • Assicurati che la replica di ripristino di emergenza esegua la stessa versione del database dell'istanza principale, PostgreSQL 12 o versioni successive.
  • Assicurati che il recupero point-in-time sia abilitato sull'istanza primaria. Per abilitare PITR, consulta Utilizzare il recupero point-in-time (PITR).
  • Assicurati che l'istanza principale e la replica di DR non abbiano il flag cloudsql.logical_decoding configurato. Nessuna delle due istanze può avere slot logici o replica logica configurati.
  • Se utilizzi un endpoint di scrittura DNS, verifica che la configurazione SSL per l'istanza principale e la replica di DR sia la stessa. Ad esempio, se la replica di DR è configurata per applicare la crittografia SSL, ma l'istanza primaria consente connessioni non criptate, i client non saranno in grado di connettersi alla nuova istanza primaria al termine dell'operazione di switchover.
  • Esegui un backup on demand dell'istanza primaria. Questo backup è una misura precauzionale in caso di ripristino da errori imprevisti.

Esegui l'operazione di switchover

Console

Per eseguire l'operazione di switchover:

  1. Nella console Google Cloud , vai alla pagina Istanze Cloud SQL.

    Vai a Istanze Cloud SQL

  2. Trova la replica RE designata dell'istanza principale.
  3. Fai clic sull'istanza di replica di ripristino di emergenza. Viene visualizzata la pagina Panoramica della replica di DR.
  4. Fai clic sul pulsante Cambio.
  5. Nella pagina Esegui il cambio tra l'istanza principale e la replica di ripristino di emergenza, inserisci il nome dell'istanza principale nel campo ID istanza.
  6. Fai clic su Passaggio.

gcloud

Per eseguire l'operazione di switchover, esegui questo comando:

gcloud sql instances switchover REPLICA_NAME
   [--db-timeout=TIMEOUT_DURATION ]

Sostituisci le seguenti variabili:

  • REPLICA_NAME: il nome della replica di DR designata con cui vuoi che l'istanza principale scambi i ruoli.
  • TIMEOUT_DURATION: facoltativo. Il periodo di timeout per consentire il completamento delle operazioni di database sull'istanza.

    • Se non specifichi questo parametro, l'operazione di switchover include un timeout di 10 minuti.

    Puoi aumentare il valore di questo timeout specificando il parametro --db-timeout. Sostituisci TIMEOUT_DURATION con un periodo di tempo della durata massima di 24 ore, inclusa una notazione iniziale per il formato. Ad esempio, per 30 secondi, specifica 30s. Per 24 ore, specifica 24h. Puoi anche specificare unità frazionarie di periodo di tempo utilizzando decimali fino a 9 cifre. Ad esempio, per 30,5 minuti, specifica 30.5m.

    Se non hai operazioni in attesa, puoi diminuire il valore di questo timeout.

Terraform

Per iniziare l'operazione di switchover, utilizza una risorsa Terraform. Per rendere la replica DR la nuova istanza primaria, utilizza il primo esempio. L'esempio contiene commenti per le modifiche alla configurazione Terraform che devi apportare per scambiare l'istanza primaria e la replica di DR.

#
# This sample provides the first part of the switchover operation and turns the DR replica
# into the new primary instance.
data "google_project" "default" {
}

resource "google_sql_database_instance" "original-primary" {
  name             = "postgres-original-primary-instance"
  region           = "us-east1"
  database_version = "POSTGRES_12"
  instance_type    = "CLOUD_SQL_INSTANCE"

  replication_cluster {
    failover_dr_replica_name = "${data.google_project.default.project_id}:postgres-dr-replica-instance"
  }

  settings {
    tier    = "db-perf-optimized-N-2"
    edition = "ENTERPRISE_PLUS"
    backup_configuration {
      enabled                        = true
      point_in_time_recovery_enabled = true
    }
  }
  # Set `deletion_protection` to true to ensure that one can't accidentally
  # delete this instance by use of Terraform whereas
  # `deletion_protection_enabled` flag protects this instance at the Google Cloud level.
  deletion_protection = false
  # Optional. Add more settings.
}

resource "google_sql_database_instance" "dr-replica" {
  name             = "postgres-dr-replica-instance"
  region           = "us-west2"
  database_version = "POSTGRES_12"
  # Change the instance type from "READ_REPLICA_INSTANCE" to "CLOUD_SQL_INSTANCE".
  instance_type = "CLOUD_SQL_INSTANCE"
  # Remove or comment out the master_instance_name from the DR replica.
  # master_instance_name = google_sql_database_instance.original-primary.name
  # Add the original primary instance to a list of replicas for the new primary.
  replica_names = [google_sql_database_instance.original-primary.name]

  # Designate the original primary instance as the DR replica of the new primary instance.
  # The format for setting the DR replica is `project-id:dr-replica-name`.
  replication_cluster {
    failover_dr_replica_name = "${data.google_project.default.project_id}:${google_sql_database_instance.original-primary.name}"
  }

  settings {
    tier    = "db-perf-optimized-N-2"
    edition = "ENTERPRISE_PLUS"
    backup_configuration {
      # Add a backup configuration section to enable automated backups and point-in-time-recovery (PITR) for the new primary instance.
      enabled                        = true
      point_in_time_recovery_enabled = true
    }
  }
  # Set `deletion_protection` to true to ensure that one can't accidentally
  # delete this instance by use of Terraform whereas
  # `deletion_protection_enabled` flag protects this instance at the Google Cloud level.
  deletion_protection = false
  # Optional. Add more settings.
}

Dopo aver apportato le modifiche, aggiorna la replica primaria e di ripristino di emergenza eseguendo terraform plan. Verifica che l'output includa Plan: 0 to add, 1 to change, 0 to destroy. Per eseguire il passaggio, esegui terraform apply.

A questo punto, l'istanza primaria originale è una replica della nuova istanza primaria. Tuttavia, questa modifica non viene applicata automaticamente allo stato di Terraform. Per rendere l'istanza principale originale una replica della nuova istanza principale nello stato di Terraform, utilizza il secondo esempio. Il secondo esempio fornisce commenti che descrivono le modifiche da apportare dopo aver eseguito il primo esempio.

# This sample provides the second part of the switchover operation and makes the original primary instance
# a replica of the new primary instance. After you run `terraform apply` for this sample, you'll see
# the following message:
#
# "No changes. Your infrastructure matches the configuration.
#
# Terraform has compared your real infrastructure against your configuration and found no differences,
# so no changes are needed.
#
# Apply complete! Resources: 0 added, 0 changed, 0 destroyed."
data "google_project" "default" {
}

resource "google_sql_database_instance" "original-primary" {
  name             = "postgres-original-primary-instance"
  region           = "us-east1"
  database_version = "POSTGRES_12"
  # Change instance type for the original primary from "CLOUD_SQL_INSTANCE" to "READ_REPLICA_INSTANCE".
  instance_type = "READ_REPLICA_INSTANCE"
  # Set master_instance_name to the the new primary instance, the old DR replica.
  master_instance_name = "postgres-dr-replica-instance"
  # replica_names = [] # If you previously defined a replica_names field in your template, then delete the DR replica
  # (new primary) from the list of replicas.  Don't delete the entire replica_names field.
  # Instead set the field to an empty string. For example, replica_names = [""].

  replication_cluster {
    # This instance no longer requires a designated DR replica since it's a replica.
    # Remove the DR replica designation by setting the field to an empty string.
    failover_dr_replica_name = ""
  }

  settings {
    tier    = "db-perf-optimized-N-2"
    edition = "ENTERPRISE_PLUS"
    backup_configuration {
      # Disable automated backups and PITR because this instance is now a replica.
      enabled                        = false
      point_in_time_recovery_enabled = false
    }
  }
  # Set `deletion_protection` to true to ensure that one can't accidentally
  # delete this instance by use of Terraform whereas
  # `deletion_protection_enabled` flag protects this instance at the Google Cloud level.
  deletion_protection = false
  # Optional. Add more settings.
}

resource "google_sql_database_instance" "dr-replica" {
  name             = "postgres-dr-replica-instance"
  region           = "us-west2"
  database_version = "POSTGRES_12"
  instance_type    = "CLOUD_SQL_INSTANCE"
  replica_names    = [google_sql_database_instance.original-primary.name]


  replication_cluster {
    failover_dr_replica_name = "${data.google_project.default.project_id}:${google_sql_database_instance.original-primary.name}"
  }

  settings {
    tier    = "db-perf-optimized-N-2"
    edition = "ENTERPRISE_PLUS"
    backup_configuration {
      enabled                        = true
      point_in_time_recovery_enabled = true
    }
  }
  # Set `deletion_protection` to true to ensure that one can't accidentally
  # delete this instance by use of Terraform whereas
  # `deletion_protection_enabled` flag protects this instance at the Google Cloud level.
  deletion_protection = false
  # Optional. Add more settings.
}

Se lo stato di Terraform viene aggiornato correttamente, quando esegui terraform plan sul secondo campione, viene visualizzato un messaggio simile al seguente:

No changes. Your infrastructure matches the configuration.

Se esegui terraform apply, ricevi un messaggio simile al seguente:

Resources: 0 added, 0 changed, 0 destroyed.

REST v1

Prima di utilizzare i dati della richiesta, apporta le sostituzioni seguenti:

  • PROJECT_ID: l'ID o il numero di progetto del progetto Google Cloud dell'istanza principale e della replica di DR.
  • REPLICA_NAME: il nome della replica di DR.

Metodo HTTP e URL: 

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

Per inviare la richiesta, espandi una di queste opzioni:

Dovresti ricevere una risposta JSON simile alla seguente:

REST v1beta4

Prima di utilizzare i dati della richiesta, apporta le sostituzioni seguenti:

  • PROJECT_ID: l'ID o il numero di progetto del progetto Google Cloud dell'istanza principale e della replica di DR.
  • REPLICA_NAME: il nome della replica di DR.

Metodo HTTP e URL: 

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

Per inviare la richiesta, espandi una di queste opzioni:

Dovresti ricevere una risposta JSON simile alla seguente:

Esegui il DR richiamando un failover della replica

In caso di errore della regione o di emergenza, puoi eseguire il ripristino di emergenza richiamando un'operazione di failover della replica nella replica di ripristino di emergenza designata. Per eseguire un failover della replica, promuovi la replica di recupero di emergenza designata. A differenza del cambio di ruolo, la promozione della replica di DR è immediata.

Poiché la replica di ripristino di emergenza assume immediatamente il ruolo di istanza principale, è possibile che la replica non contenga tutti i dati dell'istanza principale precedente a causa del ritardo di replica. Per questo motivo, un failover della replica può comportare la perdita di dati.

Nell'ambito del processo di promozione, il failover della replica esegue un backup della nuova istanza principale (l'ex replica DR) subito dopo che la replica DR diventa la nuova istanza principale. Al termine del backup, il recupero point-in-time (PITR) è completamente abilitato sulla nuova istanza principale. Il completamento di questo backup può richiedere da 5 a 15 minuti, a seconda delle dimensioni del disco della nuova (e vecchia) istanza primaria. Durante questo periodo di backup, PITR non è disponibile.

Quando la vecchia istanza principale torna online, il processo di failover della replica esegue un backup. Dopo l'esecuzione di questo backup, la vecchia istanza principale viene ricreata come replica di lettura della nuova istanza principale.

Per ulteriori informazioni sulle considerazioni relative all'utilizzo di PITR con il ripristino di emergenza avanzato, consulta Utilizzare PITR con il ripristino di emergenza avanzato.

Dopo aver richiamato l'operazione di failover della replica, l'endpoint di scrittura DNS, che in precedenza veniva risolto nella vecchia istanza principale, viene risolto nella nuova istanza principale.

Se configuri la connettività in uscita di Private Service Connect nella replica di disaster recovery (DR), la connettività in uscita continua a funzionare nella nuova istanza primaria creata quando la replica di DR viene promossa a istanza primaria dopo le operazioni di failover della replica. Se non configuri la connettività in uscita sulla replica di disaster recovery (DR), devi abilitare la connettività in uscita di Private Service Connect sulla nuova istanza primaria affinché il servizio continui a funzionare dopo le operazioni di failover della replica.

Prima di iniziare

Prima di poter eseguire un failover della replica, segui questi passaggi:

  • Se non l'hai ancora fatto, allora designa una replica di ripristino di emergenza. Puoi eseguire il failover della replica solo tra l'istanza principale e la replica di DR designata.
  • Assicurati che la replica di DR sia online e integra.
  • Assicurati che la replica di ripristino di emergenza esegua la stessa versione del database dell'istanza principale, PostgreSQL 12 o versioni successive.
  • Assicurati che il recupero point-in-time sia abilitato sull'istanza primaria. Per abilitare PITR, consulta Utilizzare il recupero point-in-time (PITR).
  • Assicurati che l'istanza principale e la replica di ripristino di emergenza non abbiano il flag cloudsql.logical_decoding configurato. Nessuna delle due istanze può avere slot logici o la replica logica configurata. Se richiami il failover della replica e la decodifica logica è abilitata nell'istanza principale originale, quando quest'ultima diventa una replica di lettura, tutti gli slot logici configurati nell'istanza principale originale vengono persi.

Esegui l'operazione di failover della replica

Console

Per eseguire l'operazione di failover della replica:

  1. Nella console Google Cloud , vai alla pagina Istanze Cloud SQL.

    Vai a Istanze Cloud SQL

  2. Fai clic sull'istanza di replica di ripristino di emergenza. Viene visualizzata la pagina Panoramica della replica di DR.
  3. Fai clic sul pulsante Failover della replica.
  4. Nella pagina Esegui il failover della replica tra l'istanza principale e la replica di ripristino di emergenza, inserisci il nome dell'istanza principale nel campo ID istanza per confermare che vuoi procedere con l'operazione.
  5. Per avviare il failover della replica, fai clic su Failover della replica.

gcloud

Per richiamare un failover della replica sulla replica di DR, utilizza il seguente comando:

gcloud sql instances promote-replica \
   REPLICA_NAME --failover

Sostituisci la seguente variabile:

  • REPLICA_NAME: il nome della replica di ripristino di emergenza

REST v1

Prima di utilizzare i dati della richiesta, apporta le sostituzioni seguenti:

  • PROJECT_ID: l'ID o il numero di progetto del progetto Google Cloud dell'istanza primaria e della replica di DR.
  • REPLICA_NAME: il nome della replica di DR.
  • ENABLE_REPLICA_FAILOVER: imposta su true per utilizzare il failover della replica. Se imposti false, l'API utilizza il normale metodo promoteReplica senza il failover della replica.

Metodo HTTP e URL: 

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

Per inviare la richiesta, espandi una di queste opzioni:

Dovresti ricevere una risposta JSON simile alla seguente:

REST v1beta4

Prima di utilizzare i dati della richiesta, apporta le sostituzioni seguenti:

  • PROJECT_ID: l'ID o il numero di progetto del progetto Google Cloud dell'istanza primaria e della replica di DR.
  • REPLICA_NAME: il nome della replica di DR.
  • ENABLE_REPLICA_FAILOVER: imposta su true per utilizzare il failover della replica. Se imposti false, l'API utilizza il normale metodo promoteReplica senza il failover della replica.

Metodo HTTP e URL: 

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

Per inviare la richiesta, espandi una di queste opzioni:

Dovresti ricevere una risposta JSON simile alla seguente:

Controllare lo stato di un failover della replica

Il failover della replica avviene in due fasi. La prima fase è la promozione della replica di DR. La seconda fase prevede la ricreazione della vecchia istanza principale come replica di lettura.

Per controllare lo stato del failover della replica, controlla lo stato di ogni fase.

  1. Controlla lo stato della prima fase.

    Console

    Per verificare se la replica di DR è stata promossa a istanza autonoma:

    1. Nella console Google Cloud , vai alla pagina Istanze Cloud SQL.

      Vai a Istanze Cloud SQL

    2. Trova il nome della replica di DR che hai promosso.
    3. Verifica che PostgreSQL VERSION venga visualizzato nella colonna Tipo per la nuova istanza primaria.

    gcloud

    Puoi controllare lo stato eseguendo il comando seguente:

    gcloud sql instances describe DR_REPLICA_NAME

    Sostituisci la seguente variabile:

    • DR_REPLICA_NAME: il nome della replica di DR promossa

    Nell'output, verifica che venga visualizzato il seguente campo e che la replica sia diventata un'istanza Cloud SQL principale autonoma:

    instanceType: CLOUD_SQL_INSTANCE

  2. Per verificare il completamento della seconda fase, controlla il log delle operazioni sull'istanza per il messaggio RECONFIGURE_OLD_PRIMARY.

    La visualizzazione di questo messaggio dipende dal momento in cui la vecchia istanza primaria torna online, il che può richiedere minuti o giorni in caso di emergenza.

    Per saperne di più su come controllare i log delle operazioni su un'istanza, consulta Visualizzare i log dell'istanza.

Utilizzare PITR con il ripristino di emergenza avanzato

Con lo switchover e il failover della replica, non appena la replica di DR viene promossa a istanza principale, vengono apportate le seguenti modifiche per supportare il backup e il PITR:

  • La configurazione del backup, inclusa qualsiasi pianificazione automatica del backup, viene copiata dalla vecchia istanza principale alla nuova istanza principale.

  • Viene eseguito un nuovo backup per supportare il PITR nella nuova istanza primaria.

  • Il criterio di conservazione dei log delle transazioni viene copiato dalla vecchia istanza principale alla nuova istanza principale.

Per le norme di conservazione dei log delle transazioni e della configurazione di backup, ti consigliamo di verificare che le impostazioni ereditate dalla vecchia istanza primaria siano corrette per la nuova istanza primaria.

Inizio della copertura PITR

Al termine dell'operazione di switchover, Cloud SQL pianifica i backup automatici ed esegue il primo backup della nuova istanza principale. Se vuoi che la copertura PITR inizi prima possibile, ti consigliamo di verificare che il primo backup vada a buon fine. L'istanza principale appena promossa ha una copertura PITR solo dopo il completamento del primo backup automatico.

Per saperne di più su come visualizzare i backup disponibili per un'istanza, consulta Visualizzare un elenco di backup.

Copertura PITR per le istanze durante il cambio e il failover della replica

Quando un'istanza partecipa a un'operazione di switchover o di failover della replica, l'istanza funge da replica di lettura. Il PITR e il ripristino di un backup sono supportati durante il periodo di tempo in cui l'istanza funge da replica di lettura e da istanza principale.

Puoi eseguire il PITR a un momento precedente al failover in cui l'istanza era un'istanza primaria. Per le operazioni di switchover e failover della replica, Cloud SQL avvia un backup con il massimo impegno per la nuova istanza primaria non appena viene promossa. PITR viene abilitato sull'istanza promossa solo dopo il completamento di questo backup. Il completamento di questo backup può richiedere da 5 a 15 minuti, a seconda delle dimensioni del disco.

Split-brain durante il failover della replica

È possibile che si verifichi uno split-brain quando l'istanza principale continua ad accettare scritture mentre una replica viene promossa utilizzando il failover della replica. Dopo la promozione della replica, quando la vecchia istanza principale è di nuovo disponibile, viene ricreata come replica dell'istanza promossa e viene eseguito un backup finale. Questo backup può essere utilizzato per recuperare i dati split-brain che non sono stati scritti nella replica promossa.

Eliminazione dei backup e dei log delle transazioni sulle repliche

Se un'istanza principale per cui sono stati abilitati PITR e backup diventa una replica di lettura, l'ultimo backup e la norma di conservazione PITR del periodo in cui era un'istanza principale vengono conservati e applicati durante il periodo in cui è una replica. Anche se la nuova istanza principale non esegue backup, i vecchi backup e i log delle transazioni utilizzati per il PITR vengono eliminati nella replica di lettura in base al criterio configurato per ultimo.

Ad esempio, se l'istanza è configurata per eseguire backup automatici giornalieri e conservare 7 backup con 7 giorni di log PITR, quando questa istanza diventa una replica di lettura, tutto ciò che risale a più di 7 giorni fa viene eliminato una volta al giorno.

Se devi eliminare i backup prima, puoi rimuoverli manualmente. Per maggiori informazioni, vedi Eliminare un backup.

Consigli per i Controlli di servizio VPC e il ripristino di emergenza avanzato

Se utilizzi Controlli di servizio VPC, assicurati che i perimetri di servizio consentano le comunicazioni necessarie per tutte le operazioni di ripristino, come le operazioni di ripristino point-in-time (PITR), soprattutto quando utilizzi CMEK con chiavi in un progetto diverso.

Le operazioni di DR avanzate, come lo switchover e il failover della replica, possono attivare o riconfigurare funzionalità come il PITR, che possono essere bloccate dai Controlli di servizio VPC se i perimetri di servizio non sono configurati correttamente per CMEK e l'accesso alle chiavi tra progetti.

  • Mantieni il progetto della chiave KMS nello stesso perimetro dell'istanza: come best practice, includi il progetto contenente la chiave KMS nello stesso perimetro dei Controlli di servizio VPC delle istanze Cloud SQL.
  • Utilizza un bridge del perimetro: come opzione secondaria (meno consigliata), puoi utilizzare un bridge del perimetro per connettere progetti in perimetri diversi.
  • Test: utilizza la modalità dry run dei Controlli di servizio VPC per testare le procedure di DR (ad esempio il failover) e identificare potenziali violazioni dei Controlli di servizio VPC senza applicazione forzata.

Per saperne di più, consulta Configura i Controlli di servizio VPC.

Limitazioni

  • Non puoi designare un'istanza di replica di lettura di Cloud SQL Enterprise Plus come replica DR se l'istanza principale archivia i log delle transazioni per il recupero point-in-time (PITR) su disco. Per controllare dove un'istanza memorizza i log per il PITR, consulta Controllare la posizione di archiviazione dei log delle transazioni utilizzati per il PITR.

  • Non puoi designare una replica esterna come replica di ripristino di emergenza.

  • Terraform non è supportato per le operazioni di failover della replica.

Risoluzione dei problemi

Problema Risoluzione dei problemi
L'operazione di switchover non è riuscita.
  • Controlla il volume delle transazioni nel database. Se il volume delle transazioni è elevato, l'operazione potrebbe scadere. Prova a ripetere l'operazione quando il carico di transazioni è inferiore.
L'operazione di switchover non è riuscita e l'istanza principale è bloccata in modalità di sola lettura. Esegui un riavvio del database per riportare l'istanza principale in modalità di scrittura.
L'operazione di trasferimento è stata completata, ma la console Google Cloud non mostra i nuovi ruoli invertiti per le istanze. Aggiorna il browser per visualizzare la topologia aggiornata.
L'operazione di failover della replica non è riuscita.
  • Se il failover alla replica di DR non è riuscito, esegui la promozione a una replica di lettura normale (non di DR).

Passaggi successivi