Informazioni sul ripristino di emergenza (RE) in Cloud SQL

Questa pagina illustra 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'istanza Cloud SQL non è più disponibile, anche il database Cloud SQL diventa non disponibile.

Per continuare l'elaborazione, devi rendere disponibile il database in una regione il prima possibile. Il piano di RE richiede la configurazione di un account tra regioni di lettura in Cloud SQL. Un failover basato su esportazione/importazione o backup/ripristino, ma questo approccio richiede più tempo, in particolare per 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 è superiore all'accordo sul livello del servizio Cloud SQL regionale (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 e l'elaborazione continua quando si verifica un'interruzione della 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 in un'altra regione è più rapido della ricreazione di un database.

In generale, il processo di RE ha due varianti:

  • Un database esegue il failover in una regione secondaria. Dopo che il database viene pronto e utilizzato da un'applicazione, diventa il nuovo database principale rimane il database principale.
  • 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 seconda variante, quando un database in errore viene recuperato e poi ritorna 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.

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 principali 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 Cloud SQL (un'istanza principale e un'istanza di standby) si trovano in due zone distinte all'interno di un'unica 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 il piano di RE, la replica di lettura tra regioni è configurata per sincronizzarsi (utilizzando la replica asincrona) con l'istanza principale utilizzando una configurazione della replica di lettura.

Le istanze principali e in standby condividono lo stesso disco regionale, quindi 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 (RE) si avvia quando la regione principale non disponibile. Per riprendere l'elaborazione in una regione secondaria, attiva un failover dell'istanza principale promuovendo una replica di lettura tra regioni. Il processo di RE indica i passaggi operativi da eseguire, manualmente o automaticamente, per mitigare l'errore a livello di regione e stabilire 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 essere il principale.

La procedura di RP 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 nella regione secondaria (R2) in modo che diventi la 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 consente di stabilire un'architettura di DR completa, in cui la nuova istanza principale stessa abbia un'istanza in standby e una replica di lettura tra regioni.

Un processo di RE completo assicura che la singola istanza, la nuova istanza principale, abilitato per l'alta disponibilità e ha una replica di lettura tra regioni. Un processo di RE completo fornisce un elemento di riserva al deployment originale nella regione principale originale.

Esecuzione del failover in una regione secondaria

Un processo di RE completo estende il processo di RE di base aggiungendo passaggi per stabilire un'architettura 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, 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) in modo che diventi la nuova istanza principale.
  4. Le connessioni client sono riconfigurate in modo da consentire l'accesso e l'elaborazione sul nuovo principale (R2).
  5. In R2 viene creata e avviata una nuova istanza in standby e aggiunta all'istanza principale. L'istanza di 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 collegato all'istanza principale. A questo punto, una catastrofe completa l'architettura di ripristino dei dati e viene ricreata e operativa.

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 uno stato di split-brain

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, un situazione di "split-brain" in cui alcuni client accedono a dati inattivi nel vecchio database primario, e altri client accedono a dati aggiornati nel nuovo database principale, il che porta a sui problemi nella tua azienda.

Per evitare una situazione di split-brain, devi assicurarti che i client non possano più accedere all'istanza principale originale dopo che 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.

Impostazione di un backup iniziale dopo il failover

Quando promuovi la replica di lettura tra regioni come nuova principale in un sistema di failover, le transazioni nella nuova principale potrebbero non essere completamente sincronizzate con le transazioni della principale originale. Pertanto, tali transazioni vengono non è disponibile nella nuova istanza.

Come best practice, ti consigliamo di eseguire immediatamente il backup della nuova all'inizio del failover e prima che i client accedano al database. Questo backup rappresenta uno stato coerente e noto 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 descritto in precedenza, questo documento illustra la procedura per eseguire il fallback alla 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é questo piano di riserva viene attivato manualmente e non si basa su un'interruzione, puoi scegliere un giorno e un'ora appropriati per questa attività di manutenzione.

Pertanto, per ottenere un DR completo con una replica di lettura principale, di riserva e tra regioni, sono necessari due failover. Il primo failover viene attivato dall'interruzione (un vero e proprio failover) e il secondo ripristina 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. Riconfigura le applicazioni in modo che si connettano alla nuova istanza principale.
  3. Crea una replica tra regioni per la nuova istanza principale nella regione di DR (R2).
  4. (Facoltativo) Per evitare di eseguire più istanze principali indipendenti, esegui la pulizia nell'istanza principale nella regione RE (R2).

Repliche con struttura a cascata

Cloud SQL consente di creare repliche per i disastri tra regioni scenari di test e ripristino. Puoi creare una replica con cascadable-replica in una regione diversa da quella principale in esecuzione in un'istanza Compute Engine. Se si verifica un'emergenza nella regione dell'istanza principale, avvia il failover alla replica con struttura a cascata. Una volta che l'istanza principale originale è tornata online e funziona come replica sana, puoi utilizzare l'operazione di switchover per tornare all'istanza principale originale.

Una replica a cascata ha due funzionalità aggiuntive le repliche di lettura non includono:

  • Puoi collegare repliche di lettura aggiuntive (repliche a cascata) alla replica di lettura con questa opzione. Cloud SQL invia il traffico di replica tra regioni alla replica a cascata solo una volta, e poi la replica a cascata inoltra il traffico alle repliche nella regione. Questa architettura consente di risparmiare sui costi di trasferimento di dati di rete tra regioni quando devi avere più repliche in un'altra regione.
  • Puoi utilizzare la replica di lettura a cascata come destinazione per il cambio e il failover in scenari di ripristino di emergenza tra regioni. Queste operazioni riconfigurare la replica a cascata in modo che sia l'istanza principale in un cluster.

Puoi testare il ripristino dei dati dopo un disastro in uno dei seguenti due modi:

  • Promozione della replica
  • Ripristino di emergenza avanzato

Ripristino di emergenza (DR) avanzato

Se utilizzi la versione Cloud SQL Enterprise Plus, puoi usufruire del ripristino di emergenza avanzato. Questa funzionalità semplifica il recupero e il fallback dopo un failover tra regioni. Come descritto nei Procedura di ripristino di emergenza. quando esegui RE, rimuovi la connessione tra la regione con errori del vecchio principale e la regione operativa della nuova istanza principale. Con il piano di RP, per ripristinare le connessioni alla regione di deployment originale e recuperare la vecchia istanza principale, 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 RE regolare, con la differenza che denominata replica di ripristino di emergenza (RE). Per Cloud SQL per SQL Server, crea una replica di DR creando una replica tra regioni dell'istanza principale con il flag cascadable-replica. La promozione della replica di RE è immediata. Inoltre, quando crei una nuova istanza principale o designi una replica di RE per un'istanza principale esistente, Cloud SQL crea un endpoint di scrittura. Un endpoint di scrittura è un nome DNS che risolve nell'indirizzo IP dell'istanza principale. Quando la replica di RE viene promossa, l'endpoint di scrittura viene aggiornato in modo che punti principale appena promossa. In questo modo, tutte le applicazioni che tentano di collegarsi utilizzando l'endpoint di scrittura vengono reindirizzate all'istanza promossa.

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, puoi eseguire il passaggio finale del piano di RP avanzato. Puoi ripristinare il deployment Cloud SQL allo stato originale e ripristinare la vecchia istanza principale (A) al suo ruolo precedente di istanza principale senza perdita di dati. Per eseguire questo ripristino senza perdita di dati della vecchia istanza principale (A), puoi utilizzare l'operazione 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 riportate ai loro ruoli originali, ripristinando così la topologia allo stato originale prima del failover della replica e del piano di recupero.

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 RE è una replica a cascata, che puoi creare con il flag cascadable-replica Per agire come replica di RE, la replica a cascata deve trovarsi in una regione separata dall'istanza principale.
  • Non puoi avere più di una replica DR in una regione.
  • Puoi modificare la designazione della replica di DR in qualsiasi momento, tranne durante un'operazione di switchover o failover della replica.

    • Inoltre, per ridurre il RTO dopo l'utilizzo del DR avanzato, ti consigliamo di procedere come segue:

    • Configura la replica di DR con le stesse dimensioni dell'istanza principale.
    • Se l'istanza principale ha l'HA abilitato, ti consigliamo di attivare l'HA anche sulla replica di DR. Per farlo, verifica innanzitutto che i valori nell'istanza principale con alta disponibilità. Poi, il passaggio alla replica di RE. 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.
    5. La replica di DR diventa immediatamente l'istanza principale e inizia ad accettare letture e scritture in entrata.
    6. L'endpoint di scrittura viene aggiornato e inizia a puntare 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 conserva il proprio indirizzo IP.
    8. Se la vecchia istanza principale non è operativa da 24 ore, Cloud SQL rimuove dalla topologia di replica per garantire che il log delle transazioni della nuova istanza principale e delle sue altre repliche non sono illimitate.

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

    Cambia

    Il cambio prevede i 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 in esecuzione. Puoi eseguire solo quando sia l'istanza principale sia la replica di RE sono online.
    3. Sei tu ad avviare il passaggio. Quando avvii il cambio, la replica alla replica RE passa alla modalità sincrona.
    4. La replica di RE raggiunge l'istanza principale e cambia il proprio stato a sincronizzato.
    5. La replica di RE raggiunge l'istanza principale cambia lo stato in Sincronizzato.
    6. Quando il ritardo della replica si azzera, la replica 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. L'endpoint di scrittura viene aggiornato e inizia a puntare al nuovo principale in esecuzione in un'istanza Compute Engine.
    9. Il PITR viene attivato automaticamente per la nuova istanza principale. Il PITR è possibile solo dopo il primo backup automatico.

    Endpoint di scrittura

    L'endpoint di scrittura è un nome di servizio DNS (Domain Name System) che risolve nell'indirizzo IP dell'istanza principale. Questo endpoint reindirizza automaticamente le connessioni in arrivo all'istanza principale in caso di failover della replica o di operazione di switchover. Puoi utilizzare l'endpoint di scrittura in una stringa di connessione SQL anziché in un indirizzo IP. Utilizzando un endpoint di scrittura, puoi evitare di dover rendere quando si verifica un'interruzione del servizio a livello di regione.

    Un endpoint di scrittura richiede che l'API Cloud DNS sia abilitata sul progetto in cui devi creare o disporre dell'istanza principale della versione Cloud SQL Enterprise Plus esistente. Quando crei un'istanza della versione Cloud SQL Enterprise Plus con un Indirizzo IP e reti autorizzate, Cloud SQL genera automaticamente un endpoint di scrittura per l'istanza. Se hai già un'istanza principale Cloud SQL Enterprise Plus, Cloud SQL genera l'endpoint di scrittura quando crei la replica di DR (una replica tra regioni creata con un flag cascadable-replica). Se l'istanza principale cambia a causa di un'operazione di switchover o di failover della replica, Cloud SQL assegna l'endpoint di scrittura alla replica di RE quando questa diventa la nuova istanza principale.

    Per ulteriori informazioni su come ottenere l'endpoint di scrittura per l'istanza, consulta Visualizza le informazioni sull'istanza. Per ulteriori informazioni sull'utilizzo dell'endpoint di scrittura per connettersi all'istanza, consulta Eseguire la connessione utilizzando un endpoint di scrittura.

    Passaggi successivi