Promozione di repliche per la migrazione a livello di area geografica o il ripristino di emergenza

Questa pagina descrive come utilizzare e promuovere le repliche di lettura tra regioni (repliche create in una regione diversa da quella della replica principale) per la migrazione tra regioni o ripristino di emergenza.

Panoramica

Esistono due scenari comuni per la promozione delle repliche tra regioni:

• Migrazione regionale: esegui una migrazione pianificata di un database in un'altra regione.
• Disaster recovery: esegui il failover di un database in un'altra regione nel caso in cui la regione principale non sia disponibile.

Entrambi i casi d'uso prevedono la configurazione della replica tra regioni e la promozione della replica. La differenza principale tra i due casi è se la promozione della replica è pianificata (nel caso della migrazione regionale) o non pianificata (è necessario un failover nella regione della replica per continuare le operazioni perché l'istanza principale non è più disponibile).

Migrazione regionale

Puoi utilizzare una replica tra regioni per eseguire la migrazione del database in un'altra regione con tempi di inattività minimi. L'idea generale è creare una replica in un'altra regione, attendere che la replica venga aggiornata, promuoverla e quindi indirizzare i client all'istanza appena promossa.

I passaggi per la promozione sono gli stessi della promozione di una replica all'interno della regione; segui queste istruzioni per assicurarti che l'istanza appena promossa abbia tutte le transazioni di cui è stato eseguito il commit nell'istanza principale originale. Dopo aver promosso la replica e verificato che l'istanza appena promossa funzioni, aggiorna tutti i client del database per connetterli alla nuova istanza.

Disaster recovery (RE)

Le repliche tra regioni possono essere utilizzate nell'ambito di una procedura di ripristino di emergenza. Puoi promuovere una replica tra regioni per eseguire il failover in un'altra regione nel caso in cui la regione dell'istanza principale non sia disponibile per un periodo di tempo prolungato.

Per saperne di più sul ripristino di emergenza, consulta Informazioni ripristino di emergenza in Cloud SQL.

Ripristino di emergenza (RE) avanzato

Se utilizzi la versione Cloud SQL Enterprise Plus, puoi designare una replica di lettura tra regioni come replica per il ripristino di emergenza (replica RE) per il ripristino di emergenza (RE) avanzato. Con RE avanzato, esegui un failover della replica per sostituire l'istanza principale con la replica di RE designata. La precedente istanza principale diventa una replica della replica di RE promossa. Puoi eseguire il failover della replica solo nella replica RE designata. Puoi comunque promuovere altre repliche di lettura senza failover.

Per riportare il deployment allo stato originale dopo il failover della replica senza perdita di dati, puoi eseguire uno switchover. Poiché la vecchia istanza principale è una replica della nuova istanza principale, puoi cambiare nuovamente i ruoli per ripristinare la vecchia istanza principale.

Per saperne di più, consulta Disaster ripristino di emergenza (RE) avanzato.

Verifica i criteri di failover

Poiché la replica è asincrona, quando si verifica un'interruzione in una regione e viene tentato un failover, alcune transazioni recenti di cui è stato eseguito il commit nell'istanza principale potrebbero andare perse (non replicate nella replica). Ogni volta che un'istanza principale non è disponibile, i passaggi seguenti mostrano (1) come determinare la quantità di dati, se presenti, che potrebbero essere andati persi nel failover tra regioni e (2) come assicurarsi che la replica promossa rifletta il maggior numero possibile di scritture recenti.

Prima di controllare il ritardo di replica o promuovere una replica, verifica lo stato della replica controllando la metrica Stato della replica (cloudsql.googleapis.com/database/replication/state) nella pagina Panoramica dell'istanza di replica nella console Cloud de Confiance :

• Durante un'interruzione principale: la metrica potrebbe segnalare Error o Stopped. Ciò indica che la replica è stata interrotta a causa dell'interruzione. Tutte le transazioni eseguite nell'istanza principale dopo l'interruzione della replica vengono perse quando promuovi la replica.
• Durante le normali operazioni (failover o migrazione pianificati): verifica che la metrica indichi Running. Se lo stato è Error o Stopped, la replica non riceve aggiornamenti dall'istanza principale. La promozione di una replica in questo stato causa la perdita di dati.

Innanzitutto, controlla il valore Replication Lag per l'istanza di replica nella dashboard di monitoraggio, che indica di quanti secondi la replica è in ritardo rispetto alla replica principale. Il valore di questa metrica nel momento immediatamente precedente all'indisponibilità della replica principale indica la finestra temporale durante la quale le transazioni di cui è stato eseguito il commit nella replica principale potrebbero essere andate perse. Ad esempio, se Replication Lag mostrava 5 secondi, è possibile che nella replica manchino le scritture nel database principale dei 5 secondi precedenti alla mancata disponibilità del database principale. La quantità effettiva di dati persi potrebbe essere inferiore a questo valore perché Replication Lag include anche le transazioni che sono state ricevute correttamente dalla replica, ma che semplicemente non sono ancora state applicate.

Quindi, connettiti all'istanza di replica con un client MySQL seguendo le istruzioni riportate nella pagina Stato della replica (consulta la scheda Client mysql). Consulta le istruzioni relative alle metriche Master_Log_File, Read_Master_Log_Pos, Relay_Master_Log_File e Exec_Master_Log_Pos. Verifica che la replica abbia elaborato tutte le transazioni ricevute dall'istanza principale. In questo modo, quando viene promossa, la replica riflette tutte le transazioni ricevute prima che la replica principale diventasse non disponibile.

Promuovi una replica di lettura

Una volta stabilito che i criteri di failover sono soddisfatti, puoi promuovere una delle repliche a un'istanza autonoma scrivibile. Considera il seguente scenario:

• La regione A (us-central1) ha un'istanza principale ad alta affidabilità (db-a-0)
• La regione B (us-west1) ha una replica ad alta affidabilità tra regioni (db-b-1) di db-a-0
• La regione C (us-east1) ha una replica tra regioni (db-c-1) di db-a-0

Puoi scegliere di promuovere db-b-1 nella Regione B in modo che diventi un'istanza scrivibile autonoma.

Per istruzioni dettagliate, consulta Promozione di una replica.

Assicurati che il tipo di macchina sia appropriato

Assicurati che il tipo di macchina dell'istanza appena promossa sia appropriato per il suo workload monitorando le metriche sull'istanza, ad esempio l'utilizzo della CPU e la memoria utilizzata. Se l'istanza appena promossa è più piccola della sua istanza principale precedente, ti consigliamo di ridimensionarla in modo che corrisponda alla sua istanza principale precedente, in modo che possa gestire la stessa quantità di carico.

Abilita l'alta affidabilità per l'istanza promossa

Per una configurazione di ripristino di emergenza, ti consigliamo di configurare la replica che intendi promuovere come replica ad alta affidabilità. In alternativa, configura la nuova istanza promossa come ad alta affidabilità. Se scegli di non configurare la replica di lettura con l'alta affidabilità, puoi anche configurare l'istanza con l'alta affidabilità se e quando la promuovi.

Quando vengono promosse, le repliche di lettura vengono configurate automaticamente con i backup. La configurazione di una replica di lettura per l'alta affidabilità viene eseguita nello stesso modo di un'istanza principale. Per saperne di più, consulta Configurazione dell'istanza per l'alta affidabilità.

Ricrea repliche aggiuntive

Se promuovi una replica in modo che diventi un'istanza principale, devi ricreare tutte le altre repliche dell'istanza principale precedente. Ad esempio, considera la configurazione a cui si fa riferimento in precedenza e ripetuta qui:

• La regione A (us-central1) ha un'istanza principale ad alta affidabilità (db-a-0)
• La regione B (us-west1) ha una replica tra regioni (db-b-1) di db-a-0
• La regione C (us-east1) ha una replica tra regioni (db-c-1) di db-a-0

Se l'istanza principale (db-a-0) non è disponibile, puoi promuovere la replica nella regione B in modo che diventi l'istanza principale. Per avere di nuovo repliche aggiuntive nelle regioni A e C, elimina le istanze precedenti (l'istanza principale precedente in A e la replica in C) e crea nuove repliche di lettura dall'istanza principale nuova in B.

La configurazione risultante sarebbe:

• La regione A (us-central1) ora ha una replica tra regioni (db-a-1)
• La regione B (us-west1) ora ha l'istanza principale (db-b-1)
• La regione C (us-east1) ora ha una nuova replica tra regioni (db-c-2)