Questa pagina è stata tradotta dall'API Cloud Translation.

Utilizza il ripristino di emergenza (RE) avanzato

MySQL | PostgreSQL | SQL Server

Questa pagina descrive come utilizzare il recupero di ripristino di emergenza (RE) avanzato. Advanced DR 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 a cascata.
Switchover consente di invertire i ruoli dell'istanza principale e di una replica di RE 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.

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 RE avanzato, crea una replica in cascata dell'istanza principale in una regione diversa da quella dell'istanza principale.

Eseguire un cambio

Dopo aver creato una replica di RE, puoi eseguire l'operazione di failover. 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 RE) non appena viene promosso. 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 PITR nell'istanza promossa, devi abilitare PITR manualmente. Per ulteriori informazioni sulle considerazioni relative all'utilizzo di PITR con il RE avanzato, consulta Utilizzare PITR con il ripristino di emergenza avanzato.

Al termine dell'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.

Prima di iniziare

Prima di eseguire l'operazione di switchover:

Se non l'hai ancora fatto, crea una RE emergenza.
Verifica che l'istanza primaria 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 sia la stessa. Ad esempio, se la replica di RE è 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 nel caso in cui sia necessario eseguire il ripristino in seguito a errori imprevisti.

Eseguire 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 primaria scambi i ruoli.

REST v1

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

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

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 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 all'interfaccia a riga di comando 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/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": "[email protected]",
  "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, apporta le seguenti sostituzioni:

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

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)

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": "[email protected]",
  "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 errore a livello di regione o di emergenza, puoi eseguire RE richiamando un'operazione di failover della replica nella replica di RE designata. Per eseguire un failover della replica, promuovi la replica REDR. A differenza del cambio di ruolo, la promozione della replica di RE è immediata.

Poiché la replica di RE di emergenza assume immediatamente il ruolo di istanza principale, è possibile che la replica 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 (l'ex replicaRER) subito dopo che la replicaRER diventa la nuova istanza principale. Al termine del 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.

Prima di iniziare

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

Se non l'hai ancora fatto, allora crea una RE emergenza.
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 di RE

REST v1

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

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.
ENABLE_REPLICA_FAILOVER: imposta su true per utilizzare il failover della replica. Se imposti false, l'API utilizza il normale metodo 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": "[email protected]",
  "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 di progetto del progetto Google Cloud dell'istanza primaria e della 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 metodo promoteReplica 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:

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/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/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:

Risposta

{
  "kind": "sql#operation",
  "targetLink": "https://sqladmin.googleapis.com/sql/v1beta4/projects/PROJECT_ID/instances/REPLICA_NAME",
  "status": "PENDING",
  "user": "[email protected]",
  "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 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 prevede la ricreazione della vecchia istanza principale come replica di lettura.

Per controllare lo stato del failover della replica, controlla lo stato di ciascuna fase.

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 di RE che hai promosso.
3. Verifica che SQL Server VERSION venga visualizzato nella colonna Tipo della 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 RE 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
```
Per verificare il completamento della seconda fase, controlla il log 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 ulteriori informazioni su come controllare i log delle operazioni su un'istanza, vedi Visualizzare i log dell'istanza.

Utilizzare PITR con RE avanzato

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

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

Per ulteriori informazioni, vedi Utilizzare PITR.

Una volta abilitato il recupero point-in-time 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 il criterio 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.

Limitazioni

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

Non puoi designare un'istanza di replica di lettura di Cloud SQL Enterprise Plus come replica RE 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 RE.
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 cambio non è riuscita.	Assicurati che l'istanza soddisfi tutti i requisiti della replica di RE(replica in cascata) indicati. 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 di 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.
L'operazione di failover della replica non è riuscita.	Assicurati di aver creato una replica di RE per l'istanza principale e che la replicaRER sia online. Se il failover alla replica di RE non è riuscito, esegui la promozione a una replica di lettura normale (non diRER).

Passaggi successivi

Visualizza tutti i serviziGoogle Cloud disponibili in località di tutto il mondo.
Scopri di più sull'osservabilità del database
Monitora le istanze Cloud SQL

Utilizza il ripristino di emergenza (RE) avanzato Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Prima di iniziare

Crea una replica RE

Eseguire un cambio

Prima di iniziare

Eseguire l'operazione di switchover

gcloud

REST v1

curl (Linux, macOS o Cloud Shell)

PowerShell (Windows)

Risposta

REST v1beta4

curl (Linux, macOS o Cloud Shell)

PowerShell (Windows)

Risposta

Esegui il DR richiamando un failover della replica

Prima di iniziare

Esegui l'operazione di failover della replica

gcloud

REST v1

curl (Linux, macOS o Cloud Shell)

PowerShell (Windows)

Risposta

REST v1beta4

curl (Linux, macOS o Cloud Shell)

PowerShell (Windows)

Risposta

Controllare lo stato di un failover della replica

Console

gcloud

Utilizzare PITR con RE avanzato

Split-brain durante il failover della replica

Eliminazione dei backup e dei log delle transazioni sulle repliche

Limitazioni

Risoluzione dei problemi

Passaggi successivi

Utilizza il ripristino di emergenza (RE) avanzato