Utilizza il ripristino di emergenza (RE) avanzato

In questa pagina viene descritto come utilizzare il disaster ripristino di emergenza (RE) avanzato. Il DR avanzato offre due funzionalità principali:

  • Il failover della replica 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 è una replica con possibilità di replica a cascata.
  • Il cambio consente di invertire i ruoli dell'istanza principale e di una replica di RE senza perdita di dati. Puoi utilizzare lo switchover per ripristinare lo stato di deployment originale dopo il failover della replica o per testare il RE.

Il DR avanzato è supportato solo nelle 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 di RE

Prima di utilizzare RE avanzato, crea una replica a cascata dell'istanza principale in una regione diversa da quella dell'istanza principale.

Esegui un cambio

Dopo aver creato una replica di RE, puoi eseguire l'operazione di switchover. Tuttavia, come best practice, evita di eseguire l'operazione di cambio 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 affidabilità (HA).

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

Al termine dello switchover, l'operazione esegue un backup della nuova istanza principale (la precedente replica di RE) non appena viene promossa. Il backup può richiedere da 5 a 15 minuti, a seconda delle dimensioni del disco. Al termine del backup, se vuoi utilizzare il PITR sull'istanza promossa, devi abilitarlo manualmente. Per ulteriori informazioni sulle considerazioni relative all'utilizzo di PITR con RE avanzato, consulta Utilizza PITR con il DR avanzato.

Una volta completata l'operazione di cambio, 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 sulla 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 sulla nuova istanza principale creata. Se non configuri la connettività in uscita sulla replica di disaster recovery (RE), per consentire al servizio di continuare a funzionare dopo le operazioni di switchover, devi abilitare la connettività in uscita di Private Service Connect sulla nuova istanza principale.

Prima di iniziare

Prima di eseguire l'operazione di switchover, segui questi passaggi:

  • Se non l'hai ancora fatto, crea una RE DR.
  • Utilizza la stored procedure sp_help_revlogin per trasferire tutti i login di SQL Server creati nell'istanza principale dopo la creazione della replica di RE. La sincronizzazione degli accessi garantisce che le applicazioni possano riconnettersi immediatamente al termine dell'operazione di cambio.
  • Verifica che l'istanza principale e la replica di RE siano online.
  • Se utilizzi un endpoint di scrittura DNS, verifica che la configurazione SSL per l'istanza principale e la replica di RE siano uguali. Ad esempio, se la replica di RE è configurata per applicare 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.
  • Esegui un backup on demand dell'istanza principale. Questo backup è una precauzione nel caso in cui sia necessario eseguire il ripristino da eventuali 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 RE con cui vuoi che l'istanza principale scambi i ruoli.

Terraform

Per avviare l'operazione di switchover, utilizza una risorsa Terraform. Per fare in modo che la replica di RE diventi la nuova istanza principale, utilizza il primo esempio. L'esempio contiene commenti per le modifiche alla configurazione di Terraform che devi apportare per cambiare 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 quella di RE eseguendo terraform plan. Verifica che l'output includa Plan: 0 to add, 1 to change, 0 to destroy. Per eseguire lo switchover, esegui terraform apply.

A questo punto, l'istanza principale originale è una replica della nuova istanza principale. Tuttavia, questa modifica non si riflette automaticamente nello stato di Terraform. Per fare in modo che l'istanza principale originale sia una replica della nuova istanza principale nello stato Terraform, utilizza il secondo esempio. Il secondo esempio fornisce commenti che descrivono le modifiche da apportare dopo l'esecuzione del 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 esempio, 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 del progetto Google Cloud dell'istanza principale e della replica di RE.
  • REPLICA_NAME: il nome della replica 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 del progetto Google Cloud dell'istanza principale e della replica di RE.
  • REPLICA_NAME: il nome della replica 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:

Esegui il DR richiamando un failover della replica

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

Poiché la replica di RE assume immediatamente il ruolo dell'istanza principale, è possibile che non contenga tutti i dati della vecchia istanza principale a causa del ritardo della 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 (la replica di RE precedente) subito dopo che la replica di RE diventa la nuova istanza principale. Una volta completato il backup, il recupero point-in-time (PITR) viene abilitato completamente sulla nuova istanza principale. Il completamento di questo backup può richiedere tra 5 e 15 minuti, a seconda delle dimensioni del disco della nuova (e della vecchia) istanza principale. Durante questo periodo di backup, la funzionalità PITR non è disponibile.

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

Per saperne di più sulle considerazioni relative all'utilizzo di PITR con RE avanzato, consulta Utilizza PITR con il DR avanzato.

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

Se configuri la connettività in uscita di Private Service Connect sulla replica di disaster recovery (RE), dopo le operazioni di failover della replica, quando la replica di RE viene promossa a istanza principale, la connettività in uscita continua a funzionare sulla nuova istanza principale creata. Se non configuri la connettività in uscita sulla replica di disaster recovery (RE), per consentire al servizio di continuare a funzionare dopo le operazioni di failover della replica, devi attivare la connettività in uscita di Private Service Connect sulla nuova istanza principale.

Prima di iniziare

Prima di poter eseguire il failover di una replica, segui questi passaggi:

  • Se non l'hai ancora fatto, crea una RE DR.
  • Se l'istanza principale è ancora accessibile, utilizza la stored procedure sp_help_revlogin per trasferire eventuali accessi SQL Server non sincronizzati alla replica di RE. La sincronizzazione di routine degli accessi garantisce che le applicazioni possano riconnettersi immediatamente dopo il failover.
  • Assicurati che la replica di RE sia online e integra.

Esegui l'operazione di failover della replica

gcloud

Per richiamare un failover della replica alla 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 di RE

REST v1

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

  • PROJECT_ID: l'ID o il numero del progetto Google Cloud dell'istanza principale e della replica di RE.
  • REPLICA_NAME: il nome della replica RE.
  • ENABLE_REPLICA_FAILOVER: impostato su true per utilizzare il failover della replica. Se imposti false, l'API utilizza il metodo promoteReplica normale senza 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 del progetto Google Cloud dell'istanza principale e della replica di RE.
  • REPLICA_NAME: il nome della replica RE.
  • ENABLE_REPLICA_FAILOVER: impostato su true per utilizzare il failover della replica. Se imposti false, l'API utilizza il metodo promoteReplica normale senza 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:

Controlla lo stato di un failover della replica

Il failover della replica avviene in due fasi. La prima fase è la promozione della replica di RE. La seconda fase è la ricreazione dell'istanza principale precedente 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 RE è stata promossa a un'istanza autonoma, segui questi passaggi:

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

      Vai a Istanze Cloud SQL

    2. Trova il nome della replica RE che hai promosso.
    3. Verifica che SQL Server VERSION venga visualizzato nella colonna Tipo per la nuova istanza principale.

    gcloud

    Puoi controllare lo stato eseguendo questo comando:

    gcloud sql instances describe DR_REPLICA_NAME

    Sostituisci la seguente variabile:

    • DR_REPLICA_NAME: il nome della replica di RE promossa

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

    instanceType: CLOUD_SQL_INSTANCE

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

    La visualizzazione di questo messaggio dipende da quando la vecchia istanza principale torna online, il che può richiedere minuti o giorni in caso di un'emergenza.

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

Utilizza il PITR con RE avanzato

Che si tratti di uno switchover o di un failover della replica, se la replica RE viene promossa a un'istanza principale e vuoi utilizzare il PITR sull'istanza promossa, devi abilitarlo manualmente.

Dopo l'attivazione del PITR, vengono applicate le policy di conservazione della configurazione di backup e del log delle transazioni. Se non specifichi i valori per queste impostazioni, viene applicato il valore predefinito di 14 giorni.

Per saperne di più, consulta Utilizza il PITR.

Dopo aver attivato il PITR sulla nuova istanza principale, puoi ripristinarla in qualsiasi momento durante il quale è un'istanza principale 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 l'istanza principale precedente è di nuovo disponibile, viene ricostruita 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 di backup e log delle transazioni sulle repliche

Se un'istanza principale abilitata per il PITR e i backup diventa una replica di lettura, l'ultimo backup e la policy di conservazione del 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 backup precedenti e i log delle transazioni utilizzati per il PITR vengono eliminati nella replica di lettura in base all'ultima policy configurata.

Ad esempio, se l'istanza è configurata per avere 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, puoi rimuoverli manualmente. Per saperne di più, consulta Elimina un backup.

Suggerimenti per i Controlli di servizio VPC e RE avanzato

Se utilizzi i Controlli di servizio VPC, assicurati che i perimetri di servizio consentano le comunicazioni necessarie per tutte le operazioni di recupero, ad esempio le operazioni di recupero 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 abilitare 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 tue istanze Cloud SQL.
  • Utilizza un bridge del perimetro: come opzione secondaria (meno consigliata), puoi utilizzare un bridge del perimetro per connettere i progetti in perimetri diversi.
  • Test: utilizza la modalità dry run dei Controlli di servizio VPC per testare le procedure di RE (come lo switchover) e identificare potenziali violazioni dei Controlli di servizio VPC senza applicazione.

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

Limitazioni

  • Non puoi designare un'istanza di replica di lettura Cloud SQL Enterprise Plus come replica di RE se l'istanza principale archivia i log delle transazioni per il recupero point-in-time (PITR) sul disco. Per verificare dove un'istanza archivia i log per il PITR, consulta Controlla la località di archiviazione dei log delle transazioni utilizzati per il PITR.

  • Non puoi designare una replica esterna come replica per RE.

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

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

Risoluzione dei problemi

Problema Risoluzione dei problemi
Operazione di switchover non riuscita.
    Assicurati che l'istanza soddisfi tutti i requisiti indicati per la replica di RE (replica con possibilità di replica a cascata).
  • 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 delle 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 switchover è stata completata, ma la console Google Cloud non mostra i nuovi ruoli invertiti per le istanze. Aggiorna il browser per visualizzare la topologia aggiornata.
Operazione di failover della replica non riuscita.
  • Assicurati di aver creato una replica di RE per l'istanza principale e che la replica di RE sia online.
  • Se il failover alla replica di RE non è riuscito, esegui la promozione a una replica di lettura normale (non di RE).

Passaggi successivi