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 creare una replica con possibilità di replica a cascata e utilizzarla come replica di 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 Google Cloud :

  • 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.

Puoi controllare lo stato della replica con la dashboard del gruppo di disponibilità Always On in SQL Server Management Studio (SSMS) o con un altro strumento. Per informazioni correlate sull'utilizzo di Transact-SQL, consulta quanto segue:

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)