Utilizza il ripristino di emergenza (RE) avanzato

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

  • Il failover della replica consente di eseguire il failover dell'istanza principale alla replica di DR immediatamente in caso di guasto regionale. Per Cloud SQL per SQL Server, la replica di RE è una replica a cascata.
  • Il cambio ti consente di invertire i ruoli dell'istanza principale e di una replica di DR senza perdita di dati. Puoi utilizzare lo switchover per ripristinare lo stato di deployment originale di un deployment dopo il failover della replica oppure per testare il DR.

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 dell'SDK Google Cloud, esegui gcloud --version. Per aggiornare l'SDK Google Cloud, esegui gcloud components update.

Per installare Google Cloud SDK, consulta Installa Google Cloud CLI.

Crea una replica RE

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

Eseguire uno switchover

Dopo aver creato una replica di DR, puoi eseguire l'operazione di switchover. Tuttavia, come best practice, evita di eseguire l'operazione di passaggio 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 passaggio quando il volume delle transazioni è ridotto.

Al termine dello switchover, l'operazione esegue il backup della nuova istanza principale (l'ex replica DR) non appena viene promossa. Il completamento del 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 abilitare manualmente il PITR. Per ulteriori informazioni sulle considerazioni relative all'utilizzo del PITR con il DR avanzato, consulta Utilizzare il PITR con il DR 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 risolveva nella vecchia istanza principale, risolve nella nuova istanza principale.

Prima di iniziare

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

  • Se non l'hai ancora fatto, crea una replica di DR.
  • Verifica che l'istanza principale e la replica di 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 principale consente connessioni non criptate, i client non potranno connettersi alla nuova istanza principale al termine dell'operazione di switchover.
  • Esegui un backup on demand dell'istanza principale. Questo backup è una misura di sicurezza nel caso in cui tu debba recuperare da eventuali errori imprevisti.

Esegui l'operazione di switchover

gcloudREST v1REST v1beta4

Per eseguire l'operazione di passaggio, esegui il seguente comando:

gcloud sql instances switchover REPLICA_NAME

Sostituisci le seguenti variabili:

  • REPLICA_NAME: il nome della replica di DR con cui vuoi che l'istanza principale cambi ruolo.

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

  • PROJECT_ID: l'ID o il numero di progetto del Google Cloud progetto dell'istanza principale e della replica di DR.
  • 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:

Esegui questo comando: 

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

Esegui questo comando: 

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

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

Dovresti ricevere una risposta JSON simile alla seguente:

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

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

  • PROJECT_ID: l'ID o il numero di progetto del Google Cloud progetto dell'istanza principale e della replica di DR.
  • 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:

Esegui questo comando: 

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

Esegui questo comando: 

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

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

Dovresti ricevere una risposta JSON simile alla seguente:

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

Esegui il DR richiamando un failover della replica

In caso di guasto regionale o di emergenza, puoi eseguire il ripristino di emergenza invocando un'operazione di failover della replica alla replica di ripristino di emergenza designata. Per eseguire un failover della replica, promuovi la replica RE. A differenza del passaggio, la promozione della replica di DR è immediata.

Poiché la replica di DR assume immediatamente il ruolo dell'istanza principale, è possibile che la replica non disponga di tutti i dati dell'istanza principale precedente 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 il 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 nella nuova istanza principale. Il completamento di questo backup può richiedere da 5 a 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 la vecchia istanza principale viene di nuovo online, il processo di failover della replica esegue un backup. Dopo aver eseguito il backup, la vecchia istanza principale viene nuovamente creata come replica di lettura della nuova istanza principale.

Per ulteriori informazioni sulle considerazioni relative all'utilizzo del PITR con il DR avanzato, consulta Utilizzare il PITR con il DR avanzato.

Dopo aver invocato l'operazione di failover della replica, l'endpoint di scrittura DNS, che in precedenza risolveva nella vecchia istanza principale, si risolve nella nuova istanza principale.

Prima di iniziare

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

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

Esegui l'operazione di failover della replica

gcloudREST v1REST v1beta4

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

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

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

Esegui questo comando: 

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

Esegui questo comando: 

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

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

Dovresti ricevere una risposta JSON simile alla seguente:

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

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

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

Esegui questo comando: 

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

Esegui questo comando: 

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

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

Dovresti ricevere una risposta JSON simile alla seguente:

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

Controllare lo stato del failover di una replica

Il failover della replica avviene in due fasi. La prima fase è la promozione della replica DR. La seconda fase consiste nella 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.

    Consolegcloud

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

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

      Vai a Istanze Cloud SQL

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

    Per controllare lo stato, esegui il seguente comando:

    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 principale Cloud SQL autonoma:

    instanceType: CLOUD_SQL_INSTANCE

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

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

    Per ulteriori informazioni su come controllare i log delle operazioni in un'istanza, vedi Visualizzare i log dell'istanza.

Utilizzare il recupero point-in-time con il ripristino dei dati di emergenza avanzato

Indipendentemente dal fatto che si tratti di uno switchover o di un failover della replica, se la replica di DR viene promossa a un'istanza principale e vuoi utilizzare la PITR nell'istanza promossa, devi attivarla manualmente.

Dopo aver attivato PITR, vengono applicati i criteri 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 ulteriori informazioni, consulta Utilizzare PITR.

Dopo aver attivato il PITR sulla nuova istanza principale, puoi ripristinarla in qualsiasi momento in cui è un'istanza principale attiva.

Stato di split-brain durante il failover della replica

È possibile che si verifichi la situazione di split-brain quando l'istanza principale continua ad accettare le 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 ricostruita come replica dell'istanza promossa e viene eseguito un backup finale. Questo backup può essere utilizzato per recuperare eventuali dati con problemi di coerenza che non sono stati scritti nella replica promossa.

Eliminazione di backup e log delle transazioni sulle repliche

Se un'istanza principale abilitata con PITR e i backup diventa una replica di lettura, l'ultimo backup e il criterio di conservazione PITR dal momento 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 i backup, i vecchi backup e i log delle transazioni utilizzati per il PITR vengono eliminati nella replica di lettura in base all'ultimo criterio configurato.

Ad esempio, se l'istanza è configurata per avere backup automatici giornalieri e mantenere 7 backup con 7 giorni di log PITR, quando questa istanza diventa una replica di lettura, tutti gli elementi precedenti a 7 giorni vengono eliminati una volta al giorno.

Se devi eliminare i backup prima, puoi rimuoverli manualmente. Per ulteriori informazioni, consulta Eliminare un backup.

Limitazioni

  • Il DR avanzato non è supportato per le istanze Cloud SQL che utilizzano Private Service Connect. Il DR avanzato supporta l'accesso privato ai servizi.

  • Non puoi designare un'istanza di replica di lettura della versione Cloud SQL Enterprise Plus come replica di DR se l'istanza principale memorizza i log delle transazioni per il recupero point-in-time (PITR) su disco. Per controllare dove un'istanza archivia 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 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
L'operazione di switchover non è riuscita.
    Assicurati che l'istanza soddisfi tutti i requisiti della replica di DR(replica con struttura a cascata) dichiarati.
  • Controlla il volume delle transazioni nel database. Se il volume delle transazioni è elevato, l'operazione potrebbe scadere. Valuta la possibilità di riprovare 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 ripristinare la modalità di scrittura dell'istanza principale.
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.
L'operazione di failover della replica non è riuscita.
  • Assicurati di aver creato una replica di DR per l'istanza principale e che la replica di DR sia online.
  • Se il failover alla replica di DR non è riuscito, esegui la promozione a una replica di lettura normale (non DR).

Passaggi successivi