Questa pagina è stata tradotta dall'API Cloud Translation.

Utilizza il ripristino di emergenza (DR) avanzato

MySQL | PostgreSQL | SQL Server

Questa pagina descrive come utilizzare il ripristino di emergenza (DR) avanzato. La DR avanzata 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 una replica di RE 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 470.0.0 o successiva e i comandi gcloud beta. 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 gcloud CLI.

Crea una replica RE

Prima di utilizzare il RE 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 le operazioni amministrative, come il backup automatico o l'abilitazione o la disattivazione dell'alta disponibilità.

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

Al termine dello switchover, l'operazione esegue il backup della nuova istanza principale (l'ex replica DR) non appena la nuova istanza principale viene promossa. Una volta completato il backup, il recupero point-in-time (PITR) completamente abilitato sulla nuova istanza principale. Il completamento del backup può richiedere da 5 a 15 minuti, a seconda delle dimensioni del disco. La copertura PITR inizia solo dopo il giorno è stato completato il backup. 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.

Prima di iniziare

Prima di eseguire il cambio, segui questi passaggi:

Se non l'hai già fatto, crea una replica RE.
Verifica che l'istanza principale e la replica di DR siano online.
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 cambio

Console

Per eseguire l'operazione di passaggio:

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

Vai a Istanze Cloud SQL
Fai clic sull'istanza della replica di RE. Viene visualizzata la pagina Panoramica della replica di DR.
Fai clic sul pulsante Cambia.
Nella sezione Esegui il cambio tra la replica principale e quella di RE inserisci il nome dell'istanza principale nel campo ID istanza.
Fai clic su Passaggio.

gcloud

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

gcloud beta sql instances switchover REPLICA_NAME

Sostituisci le seguenti variabili:

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

REST v1

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

PROJECT_ID: l'ID o il numero del progetto Google Cloud del principale e la 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:

curl (Linux, macOS o Cloud Shell)

Nota: il seguente comando presuppone che tu abbia eseguito l'accesso all'interfaccia a riga di comando gcloud con il tuo account utente eseguendo gcloud init o gcloud auth login oppure utilizzando Cloud Shell, che ti consente di accedere automaticamente all'interfaccia a riga di comando gcloud. Puoi controllare l'account attualmente attivo eseguendo gcloud auth list

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"

PowerShell (Windows)

Nota: Il comando seguente presuppone che tu abbia eseguito l'accesso a l'interfaccia a riga di comando gcloud con il tuo account utente eseguendo gcloud init o gcloud auth login di Google. Puoi controllare l'account attualmente attivo eseguendo gcloud auth list

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:

Risposta

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

REST v1beta4

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

PROJECT_ID: l'ID o il numero del progetto Google Cloud del principale e la 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:

curl (Linux, macOS o Cloud Shell)

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"

PowerShell (Windows)

Nota: il comando seguente presuppone che tu abbia eseguito l'accesso alla CLI gcloud con il tuo account utente eseguendo gcloud init o gcloud auth login . Puoi controllare l'account attualmente attivo eseguendo gcloud auth list

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:

Risposta

{
  "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 ripristino di emergenza richiamando un failover della replica

In caso di errore a livello di regione o di emergenza, puoi eseguire RE di richiamare un'operazione di failover della replica sulla replica di RE designata. Per eseguire un failover della replica, promuoverai Replica di 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 contenga 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. Questo backup può richiedere tra i 5 e i 15 minuti, a seconda delle dimensioni del disco nuovo (e precedente) dell'istanza principale. Durante questo periodo di backup, il PITR non è disponibile.

Quando la vecchia istanza principale torna online, il processo di failover della replica esegue un backup. Dopo aver eseguito il backup, la vecchia istanza principale viene rielaborata come replica di lettura della nuova istanza principale. In questo processo, la vecchia istanza principale perde i log delle transazioni PITR precedenti che non sono ancora stati salvati in Cloud Storage. Pertanto, il failover della replica non garantisce che tutti i log delle transazioni utilizzati per il PITR sulla vecchia istanza principale vengano conservati.

Per ulteriori informazioni sulle considerazioni sull'uso del PITR con RE avanzata, vedi Usa il PITR con RE avanzato.

Prima di iniziare

Prima di eseguire il 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

Console

Per eseguire l'operazione di failover della replica:

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

Vai a Istanze Cloud SQL
Fai clic sull'istanza della replica di RE. Viene visualizzata la pagina Panoramica della replica di DR.
Fai clic sul pulsante Failover della replica.
Nella pagina Esegui il failover della replica tra la replica principale e quella di RE, inserisci il nome dell'istanza principale nel campo ID istanza per confermare che vuoi continuare con l'operazione.
Per avviare il failover della replica, fai clic su Failover della replica.

gcloud

Per richiamare un failover della replica nella 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, effettua le seguenti sostituzioni:

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

curl (Linux, macOS o Cloud Shell)

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"

PowerShell (Windows)

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:

Risposta

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

REST v1beta4

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

PROJECT_ID: l'ID o il numero del progetto Google Cloud del principale e la replica di RE.
REPLICA_NAME: il nome della replica di RE.
ENABLE_REPLICA_FAILOVER: imposta su true per utilizzare il failover della replica. Se imposti false, l'API utilizza il normale valore promoteReplica senza failover della replica.

Metodo HTTP e URL:

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

Per inviare la richiesta, espandi una di queste opzioni:

curl (Linux, macOS o Cloud Shell)

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/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME/promoteReplica?failover=ENABLE_REPLICA_FAILOVER"

PowerShell (Windows)

Esegui questo comando:

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

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

Dovresti ricevere una risposta JSON simile alla seguente:

Risposta

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/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/v1beta4/projects/PROJECT_ID/operations/OPERATION_ID",
  "targetProject": "PROJECT_ID"
}

Controllare 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 consiste nella ricreazione della vecchia istanza principale come replica di lettura.

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

Controlla lo stato della prima fase.
Console

Per verificare se la replica di RE è 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 DR che hai promosso.
3. Verifica che SQL Server VERSION venga visualizzato nella colonna Tipo per la nuova istanza principale.
gcloud
Puoi verificare lo stato eseguendo questo 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 è diventata un'istanza Cloud SQL principale autonoma:
```
instanceType: CLOUD_SQL_INSTANCE
```
Per verificare il completamento della seconda fase, controlla log delle operazioni sull'istanza per il messaggio RECONFIGURE_OLD_PRIMARY.

L'aspetto di questo messaggio dipende da quando il vecchio principale restituisce online, il che può richiedere minuti giorni in caso di disastro.

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

Con il cambio e il failover della replica, non appena la replica di RE viene promosso a istanza principale, vengono apportate le seguenti modifiche per supportare il backup e PITR:

La configurazione del backup, inclusa la pianificazione automatica del backup, è dalla precedente istanza principale alla nuova istanza principale.
Se disabilitato, il flag di configurazione binlog viene attivato per abilitare PITR.
Viene eseguito un nuovo backup per supportare il PITR sulla nuova istanza principale.
Il criterio di conservazione dei log delle transazioni viene copiato dalla vecchia istanza principale alla nuova istanza principale.

Sia per la configurazione del backup sia per i criteri di conservazione dei log delle transazioni, consigliamo di verificare che le impostazioni ereditate dalla vecchia istanza principale siano corrette per la nuova istanza principale.

Inizio della copertura PITR

Al termine dell'operazione di switchover, Cloud SQL pianifica i backup automatici e esegue il primo backup della nuova istanza principale. Se vuoi che la copertura PITR inizi il prima possibile, ti consigliamo di verificare che il primo backup sia stato eseguito correttamente. L'istanza principale appena promossa ha la copertura PITR solo dopo il primo backup automatico è stato completato correttamente.

Per ulteriori informazioni su come visualizzare i backup disponibili per un consulta l'istanza Visualizza un elenco dei backup.

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

Quando un'istanza partecipa a un cambio o a un'operazione di failover della replica, l'istanza rimane inutilizzata come replica di lettura. Il PITR e il ripristino di un backup vengono supportata durante il periodo di tempo trascorso dall'istanza come replica di lettura. Se vuoi eseguire il PITR in un momento precedente all'evento di cambio (quando l'istanza era primaria), puoi inviare il comando clone avere come target l'ora in cui l'istanza è stata un'istanza principale. Non puoi richiedere PITR su un momento in cui l'istanza era una replica di lettura.

Se non riesci a eseguire il PITR perché l'istanza principale era una lettura replica al momento desiderato, dovrai tentare la richiesta PITR che era come istanza principale attiva al momento dell'interesse.

Analogamente, puoi ripristinare un backup eseguito quando la replica era un'istanza principale. Poiché l'istanza è una replica, il comando di ripristino deve avere come target un'altra istanza autonoma e non può essere ripristinato sulla replica stessa.

Per determinare quale istanza usare per la richiesta PITR, utilizza le operazioni dall'elenco di lettura. L'elenco delle operazioni per un'istanza può aiutare a determinare quando un'istanza sono state sottoposte a operazioni di cambio o failover della replica.

Split-Brain durante il failover della replica

È possibile che si verifichi " split-brain" quando l'istanza principale continua accettare scritture mentre una replica viene promossa utilizzando il failover della replica. Dopo il viene promossa, quando la vecchia istanza principale sarà di nuovo disponibile, viene ricreata come replica dell'istanza promossa e viene eseguito il backup finale. Questo il backup può essere usato per recuperare dati di tipo split-brain che non sono stati scritti replica promossa.

Eliminazione di backup e log delle transazioni sulle repliche

Se un'istanza principale che è stata abilitata con PITR e i backup diventa una risorsa automaticamente la replica, l'ultimo backup e criterio di conservazione PITR del periodo mentre l'istanza principale viene conservata e applicata durante il periodo come replica. Uniforme anche se la nuova istanza principale non sta eseguendo backup, i backup precedenti i log delle transazioni utilizzati per il PITR vengono eliminati nella replica di lettura in base l'ultimo criterio configurato.

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

La RE avanzata non è supportata per le istanze Cloud SQL che utilizzano Private Service Connect.
Non puoi designare un'istanza di replica di lettura della versione Enterprise Plus di Cloud SQL come replica di ripristino di emergenza se l'istanza principale memorizza i log delle transazioni per il recupero point-in-time (PITR) su disco. Per verificare dove si trova un'istanza archivia i propri log per PITR, Controlla la posizione di archiviazione dei log delle transazioni utilizzati per il PITR.
Non puoi designare una replica esterna come replica di RE.

Risoluzione dei problemi

Problema	Risoluzione dei problemi
Operazione di cambio non riuscita.	Assicurati che l'istanza soddisfi tutti i requisiti dichiarati per la replica di RE (replica a cascata). 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 è più basso.
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 cambio è stata completata, ma la console Google Cloud non mostra 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 RE per l'istanza principale e che la replica di RE sia online. Se il failover alla replica RE non è andato a buon fine, promuovi a un di lettura standard (non RE).

Passaggi successivi

Scopri di più sull'osservabilità del database
Monitora le istanze Cloud SQL