Utilizza il ripristino di emergenza (RE) avanzato

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

  • Il failover della replica ti consente di eseguire immediatamente il failover dell'istanza principale sulla replica di RE in caso di errore della regione. Per Cloud SQL per SQL Server, la replica di RE;emergenza è una replica a cascata.
  • Switchover consente di invertire i ruoli dell'istanza principale e di una replicaRER senza perdita di dati. Puoi utilizzare il cambio di ruolo per ripristinare uno deployment al suo stato originale dopo il failover della replica oppure puoi utilizzare il cambio di ruolo per testare iREDR.

La funzionalità Advanced DR è supportata solo sulle istanze di 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 l'Google Cloud SDK, esegui gcloud components update.

Per installare Google Cloud SDK, vedere Installare gcloud CLI.

Creare una replica di RE'emergenza

Prima di utilizzare RE avanzato, crea una replica a cascata dell'istanza primaria in una regione diversa dall'istanza primaria.

Eseguire un cambio

Dopo aver creato una replica RE, puoi eseguire l'operazione di switchover. Tuttavia, come buona prassi, si consiglia di evitare di eseguire l'operazione di switchover nelle seguenti circostanze:

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

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

Al termine del passaggio di consegne, l'operazione esegue un backup della nuova istanza primaria (la precedente replica di RE di emergenza) non appena quest'ultima viene promossa. Il completamento di questo backup può richiedere tra 5 e 15 minuti, a seconda delle dimensioni del disco. Al termine di questo backup, se vuoi utilizzare il recupero point-in-time nell'istanza promossa, devi abilitarlo manualmente. Per saperne di più sulle considerazioni relative all'utilizzo di PITR con RE avanzato, consulta Utilizzare PITR con il ripristino di emergenza avanzato.

Una volta completata l'operazione di switchover, noterai che la direzione di 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 (RE), dopo un'operazione di switchover, quando la replica di RE viene promossa a istanza principale, la connettività in uscita continua a funzionare nella nuova istanza principale creata. Se non configuri la connettività in uscita sulla replica di disaster recovery (RE), affinché il servizio continui a funzionare dopo le operazioni di switchover, devi attivare la connettività in uscita di Private Service Connect sulla nuova istanza principale.

Prima di iniziare

Prima di eseguire l'operazione di commutazione, procedere come segue:

  • Se non l'hai ancora fatto, crea una RE DR.
  • Verifica che l'istanza primaria e la replica RE siano online.
  • Se utilizzi un endpoint di scrittura DNS, verifica che la configurazione SSL per l'istanza principale e la replica di RE sia la stessa. Ad esempio, se la replica RE è configurata per applicare la crittografia SSL, ma l'istanza primaria consente connessioni non crittografate, i client non saranno in grado di connettersi alla nuova istanza primaria dopo il completamento dell'operazione di switchover.
  • Esegui un backup on demand dell'istanza primaria. Questo backup è una precauzione da adottare nel caso in cui sia necessario ripristinare i dati in seguito a guasti imprevisti.

Eseguire l'operazione di commutazione

gcloud

Per eseguire l'operazione di switchover, eseguire il seguente comando:

gcloud sql instances switchover REPLICA_NAME

Sostituisci le seguenti variabili:

  • REPLICA_NAME: il nome della replica di RE con cui vuoi che l'istanza primaria scambi i ruoli.

Terraform

Per avviare l'operazione di switchover, utilizzare una risorsa Terraform. Per rendere la replica RE 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 principale e la replica di RE.

resource "google_sql_database_instance" "original-primary" {
  name             = "sqlserver-primary-instance-name"
  region           = "us-east1"
  database_version = "SQLSERVER_2022_ENTERPRISE"
  instance_type    = "CLOUD_SQL_INSTANCE"
  root_password    = "INSERT-PASSWORD-HERE"
  replica_names    = ["sqlserver-replica-instance-name"]
  settings {
    tier    = "db-perf-optimized-N-2"
    edition = "ENTERPRISE_PLUS"
    backup_configuration {
      enabled = "true"
    }
  }
}

resource "google_sql_database_instance" "dr_replica" {
  name = "sqlserver-replica-instance-name"
  # Remove or comment out the master_instance_name
  # master_instance_name = google_sql_database_instance.original-primary.name
  region           = "us-west2"
  database_version = "SQLSERVER_2022_ENTERPRISE"
  # Change the instance type from "READ_REPLICA_INSTANCE" to "CLOUD_SQL_INSTANCE".
  instance_type = "CLOUD_SQL_INSTANCE"
  root_password = "INSERT-PASSWORD-HERE"
  # Add the original primary to the replica_names list
  replica_names = ["sqlserver-primary-instance-name"]
  # Remove or comment out the replica_configuration section
  # replica_configuration {
  #  cascadable_replica = true
  # }

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

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

A questo punto, l'istanza primaria originale è una replica della nuova istanza primaria. Tuttavia, tale modifica non si riflette automaticamente nello 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.

resource "google_sql_database_instance" "original-primary" {
  name = "sqlserver-primary-instance-name"
  # Set master_instance_name to the new primary instance, the original DR replica.
  master_instance_name = "sqlserver-replica-instance-name"
  region               = "us-east1"
  database_version     = "SQLSERVER_2022_ENTERPRISE"
  # Change the instance type from "CLOUD_SQL_INSTANCE" to "READ_REPLICA_INSTANCE".
  instance_type = "READ_REPLICA_INSTANCE"
  root_password = "INSERT-PASSWORD-HERE"
  # Remove  values from the replica_names field, but don't remove the field itself.
  replica_names = []
  # Add replica_configuration section and set cascadable_replica to true.
  replica_configuration {
    cascadable_replica = true
  }
  settings {
    tier    = "db-perf-optimized-N-2"
    edition = "ENTERPRISE_PLUS"
    backup_configuration {
      enabled = "true"
    }
  }
}

resource "google_sql_database_instance" "dr_replica" {
  name             = "sqlserver-replica-instance-name"
  region           = "us-west2"
  database_version = "SQLSERVER_2022_ENTERPRISE"
  # Change the instance type from "READ_REPLICA_INSTANCE" to "CLOUD_SQL_INSTANCE".
  instance_type = "CLOUD_SQL_INSTANCE"
  root_password = "INSERT-PASSWORD-HERE"
  # Add the original primary to the replica_names list
  replica_names = ["sqlserver-primary-instance-name"]
  settings {
    tier    = "db-perf-optimized-N-2"
    edition = "ENTERPRISE_PLUS"
  }
}

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 primaria e della replica di RE.
  • REPLICA_NAME: il nome della replica di RE.

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 primaria e della replica di RE.
  • REPLICA_NAME: il nome della replica di RE.

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:

Eseguire il ripristino di emergenza invocando un failover di replica.

In caso di guasto della regione o di disastro, è possibile eseguire il ripristino di emergenza (RE) avviando un'operazione di failover della replica verso la replica di RE designata. Per eseguire un failover della replica, promuovi la replica REDR. A differenza del passaggio di consegne, la promozione della replica di RE;emergenza è immediata.

Poiché la replica di RE assume immediatamente il ruolo di istanza principale, è possibile che la replica non contenga tutti i dati della vecchia istanza principale a causa del ritardo di replica. Per questo motivo, un failover di 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 di RE) subito dopo che la replica di RE diventa la nuova istanza principale. Al termine di questo backup, il recupero point-in-time (PITR) è completamente abilitato nella nuova istanza primaria. 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 RE 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 tuconfigurare la connettività in uscita di Private Service Connect sullareplica di ripristino di emergenza (RE) Dopo le operazioni di failover della replica, quando la replica di RE d'emergenza viene promossa a istanza primaria, la connettività in uscita continua a funzionare sulla nuova istanza primaria creata. Se non si configura la connettività in uscita sulla replica di disaster recovery (RE) , affinché il servizio continui a funzionare dopo le operazioni di failover della replica, è necessario abilitare la connettività in uscita di Private Service Connect sulla nuova istanza primaria.

Prima di iniziare

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

  • Se non l'hai ancora fatto, alloracreare una RE DR.
  • Assicurati che la replica di RE sia online e integra.

Esegui l'operazione di failover della replica

gcloud

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

gcloud sql instances promote-replica \
   REPLICA_NAME --failover

Sostituisci la seguente variabile:

  • REPLICA_NAME: il nome della replica RE

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 replicaRER.
  • REPLICA_NAME: il nome della replica di RE.
  • ENABLE_REPLICA_FAILOVER: impostato 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 principale e della replicaRER.
  • REPLICA_NAME: il nome della replica di RE.
  • ENABLE_REPLICA_FAILOVER: impostato 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:

Verifica lo stato di un failover di replica

Il failover della replica avviene in due fasi. La prima fase è la promozione della replica di RE. 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. Verifica lo stato della prima fase.

    Console

    Per verificare se la replica di RE è stata promossa a istanza autonoma, procedere come segue:

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

      Vai a Istanze Cloud SQL

    2. Trova il nome della replica di RE che hai promosso.
    3. Verifica che SQL Server 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 RE promossa

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

    instanceType: CLOUD_SQL_INSTANCE

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

    L'aspetto 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 RE avanzato

Sia in caso di switchover che di failover della replica, se la replica di RE d'emergenza viene promossa a istanza primaria e si desidera utilizzare PITR sull'istanza promossa, è necessario abilitare PITR manualmente.

Una volta abilitato PITR, vengono applicate la configurazione di backup e le politiche di conservazione del registro delle transazioni. Se non si specificano valori per queste impostazioni, viene applicato il valore predefinito di 14 giorni.

Per saperne di più, consulta la sezione Utilizzare PITR.

Dopo aver abilitato PITR sulla nuova istanza primaria, è possibile ripristinare l'istanza a qualsiasi momento in cui fosse un'istanza primaria attiva.

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 primaria non esegue backup, i vecchi backup e i log delle transazioni utilizzati per PITR vengono eliminati sulla replica di lettura in base all'ultima policy configurata.

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 è più vecchio di 7 giorni viene eliminato una volta al giorno.

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

Raccomandazioni per Controlli di servizio VPC e RE avanzato

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

Le operazioni di DR avanzate, come il cambio di ruolo 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 buona pratica, includi il progetto contenente la chiave KMS nello stesso perimetro di Controlli di servizio VPC delle tue 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 RE (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 replicaRER 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 è possibile designare una replica esterna come replica di RE.

  • Terraform non è supportato per le operazioni di failover delle repliche.

  • Non è possibile utilizzare la console Google Cloud per eseguire operazioni di failover o switchover delle repliche.

Risoluzione dei problemi

Problema Risoluzione dei problemi
L'operazione di switchover non è riuscita.
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.
  • Assicurati di aver creato una replica di ripristino d'emergenza (RE) per l'istanza primaria e che la replica di RE sia online.
  • Se il failover alla replica di RE d'emergenza non è riuscito, si procede alla promozione a una replica di lettura standard (non di RE;emergenza).

Passaggi successivi