Questa pagina descrive come utilizzare e promuovere le repliche di lettura tra regioni (repliche create in una regione diversa da quella principale) per la migrazione a livello di regione 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 una regione diversa.
- Ripristino di emergenza: esegui il failover di un database in un'altra regione nell'evento che la regione principale diventa non disponibile.
Entrambi i casi d'uso prevedono la configurazione della replica tra regioni e la successiva promozione della replica. La differenza principale è se la promozione del una replica è pianificata (nel caso di una migrazione a livello di regione) o non pianificata (un failover alla regione della replica, poiché l'istanza principale ha non saranno più disponibili).
Migrazione a livello di regione
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 indirizzare i client all'istanza appena promossa.
I passaggi per la promozione sono gli stessi per la promozione di una replica all'interno della regione. Segui queste istruzioni per assicurarti che l'istanza appena promossa contenga tutte le transazioni committate nell'istanza principale originale. Dopo aver promosso la replica e verificato che l'istanza appena promossa funziona, aggiorna tutti i client di database per eseguire la connessione alla nuova istanza.
Ripristino di emergenza (DR)
Le repliche tra regioni possono essere utilizzate nell'ambito di una procedura di ripristino di emergenza. Puoi promuovere una replica tra regioni in modo che venga eseguito 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, Informazioni sul ripristino di emergenza in Cloud SQL.
Ripristino di emergenza avanzato
Se utilizzi Cloud SQL Enterprise Plus, puoi designare una lettura tra regioni replica come replica di ripristino di emergenza (replica RE) per il ripristino di emergenza (RE). Con RE avanzato, esegui un failover della replica per sostituire principale con la replica di RE designata. L'istanza principale precedente diventa una replica la replica di RE promossa. Puoi eseguire il failover della replica solo sulla replica di ripristino di emergenza designata. Puoi comunque promuovere altre repliche di lettura senza failover.
Per ripristinare lo stato originale del deployment dopo il failover della replica senza alcuna perdita di dati, puoi eseguire uno switchover. Poiché l'istanza principale precedente è una replica della nuova istanza principale, puoi cambiare di nuovo i ruoli per ripristinare l'istanza principale precedente.
Per ulteriori informazioni, consulta Ripristino di emergenza (DR) avanzato. Il DR avanzato è in anteprima.
Verifica i criteri di failover
Poiché la replica è asincrona, quando si verifica un'interruzione a livello di regione un tentativo di failover, alcune transazioni recenti sono state l'istanza principale potrebbe andare persa (non replicata nella replica). Ogni volta che un'istanza principale diventa 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.
Innanzitutto, controlla il valore Replication Lag per l'istanza della replica nella dashboard di monitoraggio, che indica quanto tempo, in secondi, la replica è in ritardo rispetto alla principale. Il valore di questa metrica nell'istante immediatamente precedente al momento in cui la principale non è più stata disponibile indica l'intervallo di tempo durante il quale le transazioni committate alla principale potrebbero essere andate perse. Ad esempio, se
Replication Lag ha mostrato 5 secondi, poi la replica potrebbe mancare
scrive all'istanza principale nei 5 secondi precedenti la disattivazione di quella principale.
La quantità effettiva di dati persi potrebbe essere inferiore perché Replication
Lag include anche le transazioni ricevute correttamente dalla replica, ma che non sono state ancora applicate.
Quindi, connettiti all'istanza di replica con un client MySQL seguendo le
nella pagina relativa allo stato della replica (vedi la scheda Client mysql). Consulta le istruzioni relative ai
Master_Log_File, Read_Master_Log_Pos,
Relay_Master_Log_File e Exec_Master_Log_Pos
metriche di valutazione. 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 non fosse più disponibile.
Promuovere una replica di lettura
Dopo aver determinato che i criteri di failover sono soddisfatti, puoi promuovere uno dei le repliche in un'istanza autonoma scrivibile. Considera quanto segue. :
- 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 indipendente e scrivibile.
Per istruzioni dettagliate, consulta Eseguire la 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 proprio carico di lavoro monitorando le metriche ad esempio l'utilizzo di CPU e memoria. Se l'istanza appena promossa è più piccola dell'istanza principale precedente, ti consigliamo di ridimensionarla in modo che corrisponda a quella precedente in modo da poter gestire la stessa quantità di carico.
Abilita l'alta disponibilità per l'istanza promossa
Per una configurazione di disaster recovery, ti consigliamo di configurare la replica che intendi promuovere come replica ad alta disponibilità. In alternativa, configurare l'istanza appena promossa come ad alta disponibilità. Se scegli di non configurare la replica di lettura con disponibilità elevata, puoi anche configurare ad alta disponibilità se e quando lo promuovi.
Una volta promosse, le repliche di lettura vengono configurate automaticamente con i backup. La configurazione di una replica di lettura per l'alta disponibilità avviene come per una dell'istanza principale. Per saperne di più, consulta la pagina sulla configurazione dell'alta disponibilità dell'istanza.
Ricrea repliche aggiuntive
Se promuovi una replica in modo che diventi un'istanza principale, devi ricreare eventuali 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 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 è più disponibile, puoi promuovere la replica nella regione B per diventare il principale. Per avere di nuovo repliche aggiuntive nelle regioni A e C, elimina le vecchie istanze (l'ex 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 regione A (us-central1) ora ha una replica tra regioni (db-a-1)
- La regione B (us-west1) ora include l'istanza principale (db-b-1)
- La regione C (us-east1) ora ha una nuova replica tra regioni (db-c-2)