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.
- Disaster recovery: esegui il failover di un database in un'altra regione nel caso in cui la regione principale non sia più 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é la principale non è più disponibile).
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 aver verificato che l'istanza appena promossa funzioni, aggiorna tutti i client di database in modo che si connettano alla nuova istanza.
Ripristino di emergenza (RE)
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, consulta Informazioni sul ripristino di emergenza in Cloud SQL.
Verifica i criteri di failover
Poiché la replica è asincrona, quando si verifica un'interruzione del servizio a livello di regione e viene tentato un failover, alcune transazioni recenti committate nella tabella 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 presenti, che potrebbero essere andati persi durante il failover tra regioni e (2) come assicurarsi che la replica promossa rifletta il maggior numero possibile di scritture recenti.
Innanzitutto, controlla i valori Lag Bytes nella dashboard monitoring. Quando si verifica un'interruzione nella regione dell'istanza principale, viene segnalato Lag Bytes per l'istanza principale.
Quindi, connettiti all'istanza replica con un client PostgreSQL seguendo le istruzioni nella pagina Stato replica (vedi la scheda Client psql). Consulta le istruzioni relative alle metriche pg_catalog.pg_last_wal_receive_lsn() e pg_catalog.pg_last_wal_replay_lsn(). 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.
Promuovi una replica di lettura
Una volta stabilito che i criteri di failover sono soddisfatti, puoi promuovere una delle repliche a un'istanza autonoma e scrivibile. Considera il seguente scenario:
- 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 suo carico di lavoro monitorando le metriche sull'istanza, 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 all'istanza principale precedente in modo che possa gestire la stessa quantità di carico.
Attiva l'alta disponibilità per l'istanza promossa
Per una configurazione di ripristino di emergenza, ti consigliamo di configurare la replica che intendi promuovere come replica ad alta disponibilità. In alternativa, configura l'istanza appena promossa come ad alta disponibilità. Se scegli di non configurare la replica di lettura con l'alta disponibilità, puoi anche configurare l'istanza con l'alta disponibilità 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 disponibilità avviene nello stesso modo per un'istanza principale. Per ulteriori informazioni, consulta la sezione sulla configurazione dell'istanza per l'alta disponibilità.
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 è disponibile, puoi promuovere la replica nella regione B in modo che diventi quella 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 ha l'istanza principale (db-b-1)
- La regione C (us-east1) ora ha una nuova replica tra regioni (db-c-2)