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 principale) per la migrazione a livello di regione o il ripristino di emergenza.

Panoramica

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

  • Migrazione regionale: esegui una migrazione pianificata di un database in un'altra regione.
  • Ripristino di emergenza: esegui il failover di un database in un'altra regione nel caso in cui quella di quella principale non sia più disponibile.

Entrambi i casi d'uso prevedono la configurazione della replica tra regioni e la relativa promozione. La differenza principale è se la promozione della replica è pianificata (in caso di migrazione a livello di regione) o non pianificata (è necessario un failover nella regione della replica per continuare le operazioni perché quella principale è diventata non disponibile).

Migrazione a livello di regione

Puoi utilizzare una replica tra regioni per eseguire la migrazione del tuo 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 raggiunta, promuoverla e poi indirizzare i client all'istanza appena promossa.

I passaggi della promozione sono gli stessi della promozione di una replica nella regione; segui queste istruzioni per assicurarti che l'istanza appena sponsorizzata disponga di tutte le transazioni impegnate nell'istanza principale originale. Dopo aver promosso la replica e verificato che l'istanza appena promossa funzioni, aggiorna tutti i client di database per connettersi alla nuova istanza.

Ripristino di emergenza (RE)

Le repliche tra regioni possono essere utilizzate come parte di una procedura di ripristino di emergenza. Puoi promuovere una replica tra regioni in modo che venga eseguito il failover in un'altra regione nel caso in cui la regione dell'istanza principale non sia più disponibile per un periodo di tempo prolungato.

Per maggiori 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 a livello di regione e viene tentato un failover, alcune transazioni recenti di cui è stato eseguito il commit nell'unità principale potrebbero andare perse (non replicate nella replica). Ogni volta che un'istanza principale diventa non disponibile, i passaggi seguenti mostrano (1) come determinare l'eventuale quantità di dati che potrebbero essere andati persi nel failover tra regioni e (2) come garantire che la replica promossa rifletta il maggior numero possibile di scritture recenti.

Controlla innanzitutto i valori Lag Bytes nella dashboard di monitoraggio. In caso di interruzione di una regione regionale nell'istanza principale, viene segnalato Lag Bytes per l'istanza principale.

Quindi, connettiti all'istanza di replica con un client PostgreSQL seguendo le istruzioni nella pagina relativa allo stato di replica (consulta 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 quella principale diventasse non disponibile.

Promuovi una replica di lettura

Dopo aver determinato che i criteri di failover sono soddisfatti, puoi promuovere una delle repliche in un'istanza autonoma 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 ad alta disponibilità 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 autonoma scrivibile.

Vedi Promozione di una replica per istruzioni dettagliate.

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 come l'utilizzo di CPU e memoria. Se l'istanza appena promossa ha dimensioni inferiori rispetto a quella principale, ti consigliamo di ridimensionarla in modo che corrisponda a quella dell'istanza principale precedente, in modo che possa gestire la stessa quantità di carico.

Abilita l'alta disponibilità per l'istanza sponsorizzata

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 alta disponibilità. Se scegli di non configurare la replica di lettura con disponibilità elevata, puoi anche configurare l'istanza con l'alta disponibilità se e quando promuovi.

Se promosse, le repliche di lettura vengono configurate automaticamente con i backup. La configurazione di una replica di lettura per l'alta disponibilità viene eseguita come per un'istanza principale. Per saperne di più, vedi Configurare l'istanza per l'alta disponibilità.

Ricrea repliche aggiuntive

Se promuovi una replica in modo che diventi un'istanza principale, devi ricreare qualsiasi altra replica della precedente istanza principale. Ad esempio, considera la configurazione indicata 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 in modo che diventi principale. Per avere di nuovo altre repliche 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 regione A (us-central1) ha ora 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) ha ora una nuova replica tra regioni (db-c-2)