Informazioni sul ripristino di emergenza (RE) in Cloud SQL

Questa pagina introduce il ripristino di emergenza in Cloud SQL.

Panoramica

In Google Cloud, il ripristino di emergenza (RE) del database garantisce la continuità dell'elaborazione, in particolare quando una regione si arresta o non è più disponibile. Cloud SQL è un servizio a livello di regione (se Cloud SQL è configurato per l'alta disponibilità). Di conseguenza, se la regione Google Cloud che ospita un database Cloud SQL non è più 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 RE richiede la configurazione di una replica di lettura tra regioni in Cloud SQL. È anche possibile 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 garantiscono una configurazione di failover tra regioni:

  • L'accordo sul livello del servizio dell'applicazione aziendale è superiore all'accordo sul livello del servizio di Cloud SQL regionale (disponibilità del 99,99% in base alla versione di Cloud SQL in uso). Se esegui il failover in un'altra regione, puoi mitigare un'interruzione.
  • Tutti i livelli dell'applicazione aziendale sono già multiregionali e possono continuare a essere elaborati quando si verifica un'interruzione in una regione. La configurazione del failover tra regioni garantisce la disponibilità continua di un database.
  • Il Recovery Time Objective (RTO) e il Recovery Point Objective (RPO) richiesti sono in minuti anziché in ore. Il failover su un'altra regione è più veloce rispetto alla nuova creazione di un database.

In generale, il processo di RE ha due varianti:

  • Esegui il failover di un database in una regione secondaria. Quando il database è pronto e utilizzato da un'applicazione, diventa il nuovo database principale e rimane quello principale.
  • Un database esegue il failover su una regione secondaria, ma utilizza di nuovo la regione principale dopo che la regione principale viene recuperata dall'errore.

Questa panoramica del ripristino di emergenza del database Google Cloud SQL descrive la seconda variante, ovvero quando un database in errore viene recuperato e poi torna alla regione principale. Questa variante del processo di RE è particolarmente importante per i database che devono essere eseguiti nella regione principale a causa della latenza di 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 di RE sono associati due tutorial:

Architettura per il ripristino di emergenza

Il seguente diagramma mostra l'architettura minima che supporta la risposta di emergenza del database per un'istanza Cloud SQL ad alta disponibilità:

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

L'architettura funziona come segue:

  • Due istanze di Cloud SQL (un'istanza principale e un'istanza in standby) si trovano in due zone separate all'interno di una singola regione (la regione principale). Le istanze vengono sincronizzate tramite dischi permanenti a livello di regione.
  • Un'istanza di Cloud SQL (la replica di lettura tra regioni) si trova in una seconda regione (quella secondaria). Per il ripristino di emergenza, la replica di lettura tra regioni è configurata in modo da sincronizzare (utilizzando la replica asincrona) con l'istanza principale utilizzando una configurazione di replica di lettura.

Le istanze principali e in standby condividono lo stesso disco a livello di regione, quindi i loro stati sono identici.

Poiché questa configurazione utilizza la replica asincrona, è possibile che la replica di lettura tra regioni sia in ritardo rispetto all'istanza principale. Di conseguenza, quando si verifica un failover, l'RPO della replica di lettura tra regioni è probabilmente diverso da zero.

Procedura di ripristino di emergenza (RE)

Il processo di ripristino di emergenza (RE) viene avviato quando la regione principale non è più 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 prescrive i passaggi operativi da eseguire, manualmente o automaticamente, per mitigare l'errore a livello di regione e stabilire un'istanza principale in esecuzione in una regione secondaria.

Il seguente diagramma mostra il processo di RE:

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), che esegue l'istanza principale, diventa non disponibile.
  2. Il team operativo riconosce e riconosce formalmente il disastro e decide se è necessario un failover.
  3. Se è necessario un failover, puoi promuovere la replica di lettura tra regioni nella regione secondaria (R2) come nuova istanza principale.
  4. Le connessioni client sono riconfigurate per riprendere l'elaborazione nella nuova istanza 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 stessa ha un'istanza in standby e una replica di lettura tra regioni.

Un processo di RE completo garantisce che la singola istanza, la nuova istanza principale, sia abilitata per l'alta disponibilità e abbia una replica di lettura tra regioni. Un processo di RE completo fornisce inoltre un fallback al deployment originale nella regione principale originale.

Esegui il failover su una regione secondaria

Un processo di RE completo estende il processo di RE di base aggiungendo passaggi per stabilire un'architettura di RE 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 e viene configurata una replica di lettura in una terza regione.

Il processo completo di RE del database prevede i seguenti passaggi:

  1. La regione principale (R1), che esegue il database principale, non è più disponibile.
  2. Il team operativo riconosce e riconosce formalmente il disastro e decide se è necessario un failover.
  3. Se è necessario un failover, puoi promuovere la replica di lettura tra regioni nella regione secondaria (R2) come nuova istanza principale.
  4. Le connessioni client sono riconfigurate in modo da accedere alla nuova istanza principale (R2) ed elaborarla.
  5. Una nuova istanza in standby viene creata e avviata in R2 e aggiunta all'istanza principale. L'istanza in standby si trova in una zona diversa dall'istanza principale. L'istanza principale è ora ad alta disponibilità perché è stata creata un'istanza in standby.
  6. In una terza regione (R3), viene creata una nuova replica di lettura tra regioni e collegata all'istanza principale. A questo punto, viene ricreata e operativa un'architettura completa per il 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 subito nella regione R1 anziché nella regione R3. In questo caso, il fallback all'area geografica principale originale (R1) è meno complesso e richiede meno passaggi.

Evitare lo stato di "split-cervello"

Un errore della regione principale (R1) non significa che l'istanza principale originale e la sua istanza in standby vengano arrestate, rimosse o rese inaccessibili automaticamente quando R1 sarà di nuovo disponibile. Se R1 diventa disponibile, i client potrebbero leggere e scrivere dati (anche per errore) sull'istanza principale originale. In questo caso, può svilupparsi una situazione di "split-brain", in cui alcuni client accedono a dati inattivi nel vecchio database principale, mentre altri accedono a dati aggiornati nel nuovo database principale, causando problemi aziendali.

Per evitare situazioni di tipo split-brain, devi assicurarti che i client non possano più accedere all'istanza principale originale dopo che R1 diventa disponibile. Idealmente, dovresti rendere inaccessibile l'istanza principale originale prima che i client inizino a utilizzare la nuova istanza principale, quindi eliminare l'istanza 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 failover, le transazioni nella nuova istanza principale potrebbero non essere completamente sincronizzate con le transazioni dell'istanza 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 a fini normativi o per il ripristino a uno stato noto se i clienti riscontrano problemi durante l'accesso alla nuova istanza principale.

Visualizzazione della regione principale originale

Come spiegato in precedenza, questo documento illustra i passaggi per tornare all'area geografica originale (R1). Esistono due diverse versioni del processo di fallback.

  • 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 è necessario creare un'altra replica di lettura tra regioni in R1.

Una volta esistente la replica di lettura tra regioni in R1, l'istanza Cloud SQL può utilizzare il fallback R1. Poiché questo fallback viene attivato manualmente e non basato su un'interruzione, puoi scegliere un giorno e un'ora appropriati per questa attività di manutenzione.

Per ottenere un RE completo con una replica di lettura principale, in standby e tra regioni, sono necessari due failover. Il primo failover viene attivato dall'interruzione (un vero failover), mentre il secondo failover ristabilisce il deployment iniziale (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à, abilita l'alta disponibilità sull'istanza per proteggerti 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 dell'istanza principale nella regione di RE (R2).

Ripristino di emergenza avanzato

Se utilizzi Cloud SQL Enterprise Plus, puoi sfruttare il RE avanzato, che semplifica il ripristino e il fallback dopo un failover tra regioni. Come descritto nel processo di ripristino di emergenza, quando esegui RE, rimuovi la connessione tra la regione in errore della vecchia istanza principale e la regione operativa della nuova istanza principale. Con RE, per ripristinare le connessioni nella regione del deployment originale e recuperare l'istanza principale precedente, devi eseguire una serie di passaggi di fallback manuali.

Con RE avanzato, quando si verifica un errore a livello di regione, puoi richiamare un failover della replica. Con il failover della replica, promuovi una replica di lettura tra regioni simile all'esecuzione normale del ripristino di emergenza, tranne per il fatto che promuovi la replica designata per il ripristino di emergenza (RE). La promozione della replica di RE è immediata. Invece di rimuovere la vecchia istanza principale, rimane parte della topologia di replica asincrona di Cloud SQL. La vecchia istanza principale (istanza A) diventa alla fine una replica della sua replica di RE (istanza B) dopo che la replica di RE è stata promossa alla nuova istanza principale.

Dopo che la vecchia istanza principale (A) è stata trasformata in una replica, puoi eseguire il passaggio finale del RE avanzato. Puoi ripristinare lo stato originale del tuo deployment Cloud SQL e ripristinare il suo ruolo precedente come istanza principale senza perdita di dati. Per eseguire questo ripristino senza perdita di dati della vecchia istanza principale (A), puoi utilizzare l'operazione di cambio. Quando esegui un cambio, non si verifica alcuna perdita di dati perché l'istanza principale (B) rimane in modalità di sola lettura finché la sua replica di RE designata (A) non raggiunge l'istanza principale (B). Dopo che la replica di RE (A) ha ricevuto tutti i suoi aggiornamenti di replica, la replica di RE (A) assume il ruolo di istanza principale, mentre l'istanza principale precedente (B) viene riconfigurata automaticamente come replica di RE dell'istanza principale (A) attuale. Le istanze vengono restituite ai ruoli originali, ripristinando così la topologia allo stato originale prima del failover di RE e replica.

Durante RE avanzato, tutte le istanze coinvolte nelle operazioni di failover e di cambio della replica mantengono i propri indirizzi IP.

Puoi anche utilizzare l'operazione di cambio di RE avanzata per eseguire analisi di routine di emergenza al fine di testare e preparare la tua topologia Cloud SQL per il failover tra regioni prima che si verifichi un'emergenza. Se si verifica un'emergenza, puoi eseguire il failover della replica tra regioni che hai già testato.

Designata come replica per il ripristino di emergenza (RE)

Come componente obbligatorio di RE avanzato, la replica di RE ha le seguenti caratteristiche:

  • Una replica di RE è una replica di lettura interregionale connessa direttamente.
  • Puoi modificare più volte la designazione della replica RE.
  • Puoi modificare la designazione della replica RE in qualsiasi momento, tranne che durante un'operazione di cambio o failover della replica.

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

  • Configurare la replica di RE con le stesse dimensioni dell'istanza principale.
  • se nell'istanza principale è abilitata l'alta disponibilità, abilita l'alta disponibilità anche sulla replica di RE.

Failover della replica

Un failover della replica prevede i seguenti passaggi:

  1. Prima di eseguire un failover della replica, hai assegnato una replica di RE all'istanza principale e probabilmente hai testato il processo eseguendo un cambio.
  2. La regione principale, in cui è in esecuzione il database principale, non è più disponibile.
  3. Il team operativo decide che è necessario un ripristino di emergenza.
  4. Esegui il failover della replica sulla replica di RE designata.
  5. La replica di RE designata tra regioni diventa immediatamente l'istanza principale e inizia ad accettare letture e scritture in entrata.
  6. A questo punto, devi configurare le applicazioni in modo che puntino alla nuova istanza principale.
  7. Quando la vecchia istanza principale torna disponibile, diventa una replica di lettura della nuova istanza principale. La vecchia istanza principale conserva il proprio indirizzo IP.

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

Cambia

Il cambio prevede i seguenti passaggi:

  1. Prima di avviare l'operazione di switchover, devi assegnare una replica di RE all'istanza principale.
  2. Verifica che l'istanza principale sia integro. Puoi eseguire un cambio solo quando sia l'istanza principale sia la replica di RE sono online.
  3. Avvia il cambio. Quando avvii il cambio, l'istanza principale smette di accettare scritture e diventa di sola lettura.
  4. Attendi che i log binari vengano copiati in Cloud Storage.
  5. La replica designata di RE raggiunge l'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 inizia ad accettare connessioni in entrata, incluse le operazioni di lettura e scrittura dell'applicazione.
  7. La vecchia istanza principale è riconfigurata come replica di lettura.
  8. A questo punto, devi configurare le applicazioni in modo che puntino alla nuova istanza principale.
  9. Il PITR viene abilitato automaticamente per la nuova istanza principale. Il PITR è possibile solo dopo il primo backup automatico.

Passaggi successivi

  • Esplora le architetture di riferimento, i diagrammi, i tutorial e le best practice su Google Cloud. Visita il nostro Cloud Architecture Center.