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. Per Cloud SQL per SQL Server, la replica DR è una replica a cascata.
  • 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.

Crea una replica RE

Prima di utilizzare il DR avanzato, crea una replica a cascata dell'istanza primaria in una regione diversa da quella dell'istanza primaria.

Eseguire un cambio

Dopo aver creato una replica DR, 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. Il completamento di questo backup può richiedere dai 5 ai 15 minuti, a seconda delle dimensioni del disco. Al termine di questo backup, se vuoi utilizzare PITR sull'istanza promossa, devi abilitare PITR manualmente. 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.

Prima di iniziare

Prima di eseguire l'operazione di switchover:

  • Se non l'hai ancora fatto, crea una replica di ripristino di emergenza.
  • Verifica che l'istanza principale e la replica DR siano online.
  • 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

gcloud

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

gcloud sql instances switchover REPLICA_NAME

Sostituisci le seguenti variabili:

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

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.

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

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

Prima di iniziare

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

Esegui l'operazione di 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 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 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

Che si tratti di un cambio di ruolo o di un failover della replica, se la replica di DR viene promossa a istanza primaria e vuoi utilizzare PITR sull'istanza promossa, devi attivare manualmente PITR.

Una volta abilitato il PITR, vengono applicate le norme di configurazione del backup e di conservazione dei log delle transazioni. Se non specifichi i valori per queste impostazioni, viene applicato il valore predefinito di 14 giorni.

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

Dopo aver abilitato il PITR sulla nuova istanza primaria, puoi ripristinarla in qualsiasi momento in cui è 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 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 i 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.

  • Non puoi utilizzare la console Google Cloud per eseguire operazioni di failover o switchover della replica.

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 di emergenza per l'istanza principale e che la replica di ripristino di emergenza sia online.
  • Se il failover alla replica di DR non è riuscito, esegui la promozione a una replica di lettura normale (non di DR).

Passaggi successivi