Questa pagina descrive come utilizzare e promuovere le repliche di lettura tra regioni (repliche create in una regione diversa da quella dell'istanza principale) per la migrazione regionale o il 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 dell'istanza principale diventi non disponibile.
Entrambi i casi d'uso prevedono la configurazione della replica tra regioni e la successiva promozione della replica. La differenza principale tra i due è 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 si aggiorni, promuoverla e quindi indirizzare i client alla nuova istanza promossa.
I passaggi coinvolti nella promozione sono gli stessi della promozione di una replica nella regione; segui queste istruzioni per assicurarti che la nuova istanza promossa contenga tutte le transazioni di cui è stato eseguito il commit nell'istanza principale originale. Dopo aver promosso la replica e verificato che la nuova istanza promossa funzioni, aggiorna tutti i client di database in modo che si connettano alla nuova istanza.
Disaster recovery (RE)
Le repliche tra regioni possono essere utilizzate come parte di una procedura di ripristino di emergenza. Puoi promuovere una replica tra regioni per eseguire il failover in un'altra regione se la regione dell'istanza principale non è disponibile per un periodo di tempo prolungato.
Per ulteriori informazioni sul ripristino di emergenza, consulta Informazioni sul ripristino di emergenza in Cloud SQL.
Ripristino di emergenza avanzato
Se utilizzi Cloud SQL Enterprise Plus Edition, puoi designare una replica di lettura tra regioni come replica per il ripristino di emergenza (replica RE) per il ripristino di emergenza avanzato. Con RE avanzato, esegui un failover della replica per sostituire l'istanza principale con la replica RE designata. La vecchia istanza principale diventa una replica della replica RE promossa. Puoi eseguire il failover della replica solo sulla 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 un cambio. Poiché la vecchia istanza principale è una replica della nuova istanza principale, puoi scambiare di nuovo i ruoli per ripristinare la vecchia istanza principale.
Per ulteriori informazioni, consulta Disaster ripristino di emergenza (RE) avanzato.
Verificare i criteri di failover
Poiché la replica è asincrona, quando si verifica un'interruzione della 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 diventa non disponibile, i passaggi seguenti mostrano (1) come determinare la quantità di dati, se presente, che potrebbe essere andata persa nel failover tra regioni e (2) come assicurarsi che la replica promossa rifletta il maggior numero possibile di scritture recenti.
Innanzitutto, controlla il valore Replication Lag per l'istanza di replica in
nella dashboard di monitoraggio, che indica il ritardo, in secondi, della
replica rispetto all'istanza principale. Il valore di questa metrica nel momento immediatamente precedente alla non disponibilità dell'istanza principale indica la finestra di tempo durante la quale le transazioni di cui è stato eseguito il commit nell'istanza principale potrebbero essere andate perse. Ad esempio, se Replication Lag mostra 5 secondi, la replica potrebbe non includere le scritture nell'istanza principale eseguite nei 5 secondi precedenti alla non disponibilità dell'istanza principale.
(La quantità effettiva di dati persi potrebbe essere inferiore perché Replication
Lag include anche le transazioni ricevute correttamente dalla
replica, ma non ancora applicate.)
Quindi, connettiti all'istanza di replica con un client MySQL seguendo le
istruzioni riportate nella pagina dello stato della replica (vedi la scheda Client mysql). Consulta le istruzioni relative alle
Master_Log_File, Read_Master_Log_Pos,
Relay_Master_Log_File, e Exec_Master_Log_Pos
metriche. 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 l'istanza principale diventasse non disponibile.
Promuovere una replica di lettura
Una volta stabilito che i criteri di failover sono soddisfatti, puoi promuovere una delle repliche a un'istanza scrivibile e autonoma. Considera lo scenario seguente:
- La regione A (us-central1) ha un'istanza principale ad alta disponibilità (db-a-0)
- La regione B (us-west1) ha una replica tra regioni ad alta disponibilità (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 Promuovere una replica.
Assicurarsi che il tipo di macchina sia appropriato
Assicurati che il tipo di macchina della nuova istanza promossa sia appropriato per il relativo carico di lavoro monitorando le metriche dell'istanza, come l'utilizzo di CPU e memoria utilizzata. Se la nuova istanza promossa è più piccola della precedente istanza principale, ti consigliamo di ridimensionarla in modo che corrisponda alla precedente istanza principale, in modo che possa gestire la stessa quantità di carico.
Abilitare 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 disponibilità. Se scegli di non configurare la replica di lettura con l'alta affidabilità, puoi anche configurare l'istanza con l'alta affidabilità quando la promuovi.
Una volta 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 ulteriori informazioni, consulta Configurare l'istanza per l'alta affidabilità.
Ricreare repliche aggiuntive
Se promuovi una replica in modo che diventi un'istanza principale, devi ricreare tutte le altre repliche della precedente istanza principale. Ad esempio, considera la configurazione a cui abbiamo fatto riferimento in precedenza e che riportiamo di seguito:
- La regione A (us-central1) ha un'istanza principale ad alta disponibilità (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 vecchie istanze (la precedente istanza principale in A, e la replica in C) e crea nuove repliche di lettura dalla nuova istanza principale in B.
La configurazione risultante sarà la seguente:
- 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)