Informazioni sul ripristino di emergenza (DR) in Cloud SQL

Questa pagina introduce il ripristino di emergenza in Cloud SQL.

Panoramica

In Google Cloud, il ripristino di emergenza (RE) del database consiste nel garantire la continuità dell'elaborazione, in particolare quando una regione non funziona o non è disponibile. Cloud SQL è un servizio regionale (quando Cloud SQL è configurato per l'alta disponibilità (HA). Pertanto, se la regione Google Cloud che ospita un database Cloud SQL diventa non disponibile, anche il database Cloud SQL diventa non disponibile.

Per continuare l'elaborazione, devi rendere il database disponibile in una regione secondaria il prima possibile. Il piano di ripristino di emergenza richiede la configurazione di una replica di lettura tra regioni in Cloud SQL. È possibile anche un failover basato su esportazione/importazione o backup/ripristino, ma questo approccio richiede più tempo, soprattutto per i database di grandi dimensioni.

I seguenti scenari aziendali sono esempi che richiedono una configurazione di failover tra regioni:

  • L'accordo sul livello del servizio dell'applicazione aziendale è maggiore di regionale Accordo sul livello del servizio di Cloud SQL (disponibilità del 99,99% a seconda della versione di Cloud SQL). Eseguendo il failover su un'altra regione, puoi mitigare un'interruzione del servizio.
  • Tutti i livelli dell'applicazione aziendale sono già multiregionali e possono continuare l'elaborazione in caso di interruzione del servizio in una regione. Failover tra regioni garantisce la disponibilità continua di un database.
  • Il Recovery Time Objective (RTO) e il Recovery Point Objective richiesti (RPO) sono espresse in minuti anziché in ore. Il failover in un'altra regione è più rapido della ricreazione di un database.

In generale, esistono due varianti per il processo di RE:

  • Un database esegue il failover in una regione secondaria. Una volta che il database è pronto e utilizzato da un'applicazione, diventa il nuovo database principale e rimane tale.
  • Un database esegue il failover su una regione secondaria, ma utilizza di nuovo principale dopo che quest'ultima è stata recuperata dall'errore.

Questa panoramica del ripristino di emergenza del database Google Cloud SQL descrive la seconda variante, ovvero quando un database con errori viene recuperato e passa alla regione principale. Questa variante del processo di DR è particolarmente pertinente per i database che devono essere eseguiti nella regione principale a causa della latenza della rete o perché alcune risorse sono disponibili solo nella regione principale. Con questa variante, il database viene eseguito nella regione secondaria solo per la durata dell'interruzione nella regione principale.

A questo documento DR sono associati due tutorial:

Architettura per il ripristino di emergenza

Il seguente diagramma mostra l'architettura minima che supporta il DR del database per un'istanza Cloud SQL ad alta disponibilità:

Le istanze principale e in standby si trovano in una regione e la replica di lettura si trova in una seconda regione.

L'architettura funziona come segue:

  • Due istanze di Cloud SQL (una principale e una in standby) si trovano in due zone distinte all'interno di una singola regione (la regione principale). Le istanze vengono sincronizzate mediante dei dischi permanenti standard.
  • Un'istanza di Cloud SQL (la replica di lettura tra regioni) che si trovano in una seconda regione (la regione secondaria). Per RE, la risposta tra regioni la replica di lettura è configurata in modo da sincronizzare (utilizzando la replica asincrona) con l'istanza principale utilizzando una configurazione di replica di lettura.

Le istanze principale e in standby condividono lo stesso disco regionale, pertanto i relativi stati sono identici.

Poiché questa configurazione utilizza la replica asincrona, è possibile che la replica di lettura tra regioni è in ritardo rispetto all'istanza principale. Di conseguenza, quando si verifica un failover, è probabile che il RPO della replica di lettura tra regioni non sia pari a zero.

Procedura di ripristino di emergenza (DR)

Il processo di ripristino di emergenza (DR) inizia quando la regione principale diventa disponibile. Per riprendere l'elaborazione in una regione secondaria, attivi un failover dell'istanza principale promuovendo una replica di lettura tra regioni. Il processo di RE prescribe i passaggi operativi che devono essere eseguiti, manualmente o automaticamente, per mitigare l'errore regionale e stabilire un'istanza principale in esecuzione in una regione secondaria.

Il seguente diagramma mostra la procedura di DR:

Quando la regione 1 non è più disponibile, la replica di lettura originale viene promossa a principale.

Il processo di RE prevede i seguenti passaggi:

  1. La regione principale (R1), in cui è in esecuzione l'istanza principale, diventa non disponibile.
  2. Il team operativo riconosce e conferma formalmente la catastrofe e decide se è necessario un failover.
  3. Se è necessario un failover, puoi promuovere la replica di lettura tra regioni la regione secondaria (R2) come nuova istanza principale.
  4. Le connessioni client sono riconfigurate per riprendere l'elaborazione sul nuovo principale e accedere all'istanza principale in R2.

Questo processo iniziale stabilisce di nuovo un database primario funzionante. Tuttavia, non stabilisce un'architettura di RE completa, in cui la nuova istanza principale ha un'istanza in standby e una replica di lettura tra regioni.

Una procedura di DR completa garantisce che la singola istanza, la nuova principale, sia attivata per l'HA e abbia una replica di lettura tra regioni. Un processo di RE completo fornisce un elemento di riserva al deployment originale nella regione principale originale.

Esegui il failover su una regione secondaria

Un processo di DR completo estende la procedura di DR di base aggiungendo passaggi per stabilire un'architettura di DR completa dopo il failover. Il seguente diagramma mostra un'architettura completa di RE del database dopo il failover:

I client iniziano ad accedere alla nuova istanza principale ed è configurata una replica di lettura in una terza regione.

La procedura completa di DR del database è costituita dai seguenti passaggi:

  1. La regione principale (R1), che esegue il database principale, diventa non disponibile.
  2. Il team operativo riconosce e conferma formalmente la catastrofe e decide se è necessario un failover.
  3. Se è necessario un failover, puoi promuovere la replica di lettura tra regioni nella regione secondaria (R2) in modo che diventi la nuova istanza principale.
  4. Le connessioni dei client vengono riconfigurate per l'accesso e l'elaborazione sulla nuova istanza principale (R2).
  5. In R2 viene creata e avviata una nuova istanza in standby e aggiunta all'istanza principale. L'istanza in standby si trova in una zona diversa da dell'istanza principale. L'istanza principale ora è altamente disponibile perché è stata creata un'istanza di riserva.
  6. In una terza regione (R3), viene creata una nuova replica di lettura collegato all'istanza principale. A questo punto, viene ricreata e operativa un'architettura completa di ripristino di emergenza.

Se la regione principale originale (R1) diventa disponibile prima dell'implementazione del passaggio 6, la replica di lettura tra regioni può essere posizionata immediatamente nella regione R1 anziché nella regione R3. In questo caso, il codice di riserva regione (R1) è meno complessa e richiede meno passaggi.

Evitare lo stato di "split-cervello"

Un errore nella regione principale (R1) non significa che l'istanza principale originale e la relativa istanza di standby vengano arrestate, rimosse o rese inaccessibili automaticamente quando R1 diventa di nuovo disponibile. Se R1 diventa disponibile, i client potrebbero leggere e scrivere dati (anche per errore) nell'istanza principale originale. In questo caso, può verificarsi una situazione di split-brain, in cui alcuni client accedono a dati obsoleti nel vecchio database principale e altri accedono a dati aggiornati nel nuovo database principale, causando problemi nella tua attività.

Per evitare una situazione di sdoppio, devi assicurarti che i clienti non possano più accedere all'istanza principale originale quando R1 diventa disponibile. Idealmente, dovresti rendere la principale originale inaccessibile prima che i client inizino a utilizzare la nuova istanza principale, quindi eliminare la principale originale subito dopo averla resa inaccessibile.

Definizione di un backup iniziale dopo il failover

Quando promuovi la replica di lettura tra regioni come nuova istanza principale in un le transazioni nella nuova istanza principale potrebbero non essere completamente sincronizzate con transazioni della società principale originale. Pertanto, queste transazioni non sono disponibili nella nuova istanza.

Come best practice, ti consigliamo di eseguire immediatamente il backup della nuova istanza principale all'inizio del failover e prima che i client accedano al database. Questo backup rappresenta uno stato noto e coerente al momento del failover. Questi backup possono essere importanti per scopi normativi o per ripristinare uno stato conosciuto se i client riscontrano problemi di accesso al nuovo principale.

Ritorno alla regione principale originale

Come accennato in precedenza, questo documento illustra i passaggi da seguire per regione originale (R1). Esistono due versioni diverse del processo di riserva.

  • Se hai creato la nuova replica di lettura tra regioni in una regione terziaria (R3), devi creare un'altra (seconda) replica di lettura tra regioni nella regione principale (R1).
  • Se hai creato la nuova replica di lettura tra regioni nella regione principale (R1), non devi creare un'altra replica di lettura tra regioni in R1.

Una volta esistente la replica di lettura tra regioni in R1, può ricorrere a R1. Poiché la creatività di riserva viene attivata manualmente, non in base a un'interruzione, puoi scegliere il giorno e l'ora appropriati per attività di manutenzione.

Di conseguenza, per ottenere un RE completo che abbia un'istanza principale, in standby e tra regioni di lettura, sono necessari due failover. Il primo failover viene attivato (un vero failover) e il secondo failover ripristina la configurazione iniziale un deployment (un fallback).

Il fallback alla regione principale originale (R1) prevede i seguenti passaggi:

  1. Promuovi la replica tra regioni appena creata nella regione principale originale (R1).
  2. Se l'istanza promossa non è stata creata originariamente come replica ad alta disponibilità, e poi abilitare l'alta disponibilità sull'istanza per la protezione da errori a livello di zona.
  3. Riconfigura le applicazioni in modo che si connettano alla nuova istanza principale.
  4. Crea una replica tra regioni per la nuova istanza principale nella regione di RE (R2).
  5. (Facoltativo) Per evitare di eseguire più istanze principali indipendenti, esegui la pulizia nell'istanza principale nella regione RE (R2).

Ripristino di emergenza avanzato

Se utilizzi Cloud SQL Enterprise Plus, puoi approfittare di della RE avanzata. Il RE avanzato semplifica il ripristino e il fallback dopo tra regioni diverse. Come descritto nella procedura di ripristino di emergenza, quando esegui il ripristino di emergenza, rimuovi la connessione tra la regione con errori della vecchia istanza principale e la regione operativa della nuova istanza principale. Con RE, per ripristinare le connessioni nella regione di deployment originale e recuperare il vecchio principale, devi eseguire una serie di passaggi di fallback manuali.

Con il DR avanzato, quando si verifica un errore regionale, puoi invocare un failover della replica. Con il failover della replica, promuovi una replica di lettura tra regioni simile RE regolare, con la differenza che denominata replica di ripristino di emergenza (RE). La promozione della replica DR è immediata.

Invece di rimuovere l'istanza principale precedente, l'istanza rimane parte della topologia di replica asincrona di Cloud SQL. La vecchia istanza principale (istanza A) diventa alla fine un della sua replica RE (istanza B) dopo che la replica di RE alla nuova istanza principale.

Dopo che la vecchia istanza principale (A) è stata trasformata in una replica, eseguire l'ultimo passaggio del RE avanzato. Puoi restituire l'accesso a Cloud SQL allo stato originale del deployment e ripristinare la vecchia istanza principale (A) al suo ruolo precedente di istanza principale senza perdita di dati. Per eseguire questa operazione e senza alcuna perdita di dati della vecchia istanza principale (A), puoi utilizzare di switchover. Quando esegui il cambio, non si verificano perdite di dati perché l'istanza principale (B) rimane in modalità di sola lettura fino a quando la sua replica di RE designata (A) raggiunge l'istanza principale (B). Dopo che la replica RE (A) ha ricevuto tutti gli aggiornamenti di replica, la replica RE (A) assume il ruolo di istanza principale mentre l'istanza principale precedente (B) viene riconfigurata automaticamente come replica di RE dell'istanza principale attuale (A). Le istanze vengono restituite allo stato originale ruoli, ripristinando così la topologia allo stato originale prima di RE e replica di failover.

Durante il DR avanzato, tutte le istanze coinvolte sia nelle operazioni di failover della replica sia nelle operazioni di switchover mantengono i propri indirizzi IP.

Puoi anche utilizzare l'operazione di cambio del RE avanzato per eseguire la RE di routine con esercitazioni per testare e preparare la tua topologia Cloud SQL per le regioni il failover prima che si verifichi un'emergenza. Se si verifica una vera e propria disastro, puoi eseguire il failover della replica tra regioni che hai già testato.

Replica per il ripristino di emergenza (DR)

In qualità di componente obbligatorio del DR avanzato, la replica RE presenta le seguenti caratteristiche:

  • Una replica di DR è una replica di lettura tra regioni collegata direttamente.
  • Puoi modificare la designazione della replica di DR più volte.
  • Puoi modificare la designazione della replica di DR in qualsiasi momento, tranne durante un'operazione di switchover o failover della replica.

Inoltre, per ridurre l'RTO dopo aver utilizzato il RE avanzato, ti consigliamo di farlo le seguenti:

  • Configura la replica di DR con le stesse dimensioni dell'istanza principale.
  • Se l'istanza principale ha l'alta disponibilità abilitata, ti consigliamo di abilitare l'alta disponibilità anche sulla replica RE. Per farlo, verifica innanzitutto che i valori nell'istanza principale con alta disponibilità. Quindi, effettua il passaggio alla replica di DR. L'operazione di commutazione completa, abilita l'alta disponibilità sulla nuova istanza principale. Dopodiché puoi tornare indietro all'istanza principale precedente. La replica di RE conserva la configurazione ad alta disponibilità anche quando diventa di nuovo una replica.

Failover della replica

Un failover della replica è costituito dai seguenti passaggi:

  1. Prima di eseguire il failover della replica, hai assegnato una replica RE principale ed eventualmente testato il processo eseguendo una il cambio.
  2. La regione principale, in cui è in esecuzione il database principale, diventa disponibile.
  3. Il team operativo decide che è necessario un ripristino di emergenza.
  4. Esegui un failover della replica sulla replica RE designata tra regioni.
  5. La replica designata tra regioni di RE diventa immediatamente l'istanza principale e inizia ad accettare i dati in entrata operazioni di lettura e scrittura.
  6. Al momento, devi configurare le applicazioni in modo che puntino alla nuova istanza principale.
  7. Dopo aver promosso la replica, Cloud SQL controlla periodicamente se l'istanza principale originale è di nuovo online. Se l'istanza principale originale è online, Cloud SQL riconfigura l'istanza principale precedente come replica dell'istanza promossa. La vecchia istanza principale mantiene il proprio indirizzo IP.

Dopo aver eseguito il failover della replica, puoi ripristinare l'istanza principale la regione originale eseguendo l'operazione di cambio, invertendo la stessa replica di RE e coppia di istanze principali.

Cambia

Un passaggio di proprietà è costituito dai seguenti passaggi:

  1. Prima di avviare l'operazione di cambio, devi assegnare un RE replica all'istanza principale.
  2. Verifica che l'istanza principale sia integro. Puoi eseguire solo quando sia l'istanza principale sia la replica di RE sono online.
  3. Avvia il cambio. Quando avvii un cambio, l'istanza principale l'istanza smette di accettare scritture e diventa di sola lettura.
  4. Attendi che i log binari vengano copiati in Cloud Storage.
  5. La replica di DR designata si allinea all'istanza principale.
  6. Quando il ritardo della replica scende a zero, la replica di RE viene promossa come nuova istanza principale. La nuova istanza principale viene avviata che accetta connessioni in entrata, incluse letture e scritture dell'applicazione.
  7. La vecchia istanza principale è riconfigurata come replica di lettura.
  8. A questo punto, devi configurare le applicazioni in modo che puntino al nuovo dell'istanza principale.
  9. Il PITR viene abilitato automaticamente per la nuova istanza principale. Il PITR è possibile solo dopo il primo backup automatico.

Passaggi successivi