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 si arresta 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 è superiore all'accordo sul livello del servizio Cloud SQL regionale (disponibilità del 99,99% a seconda della versione di Cloud SQL). Eseguendo il failover in un'altra regione, puoi attenuare un'interruzione.
• Tutti i livelli dell'applicazione aziendale sono già multiregionali e possono continuare l'elaborazione in caso di interruzione del servizio 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 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 in una regione secondaria, ma torna alla regione principale dopo che questa è stata ripristinata dall'errore.

Questa panoramica del ripristino di emergenza del database Google Cloud SQL descrive la seconda variante: 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 RE sono associati due tutorial:

• Ripristino di emergenza Cloud SQL per MySQL: un processo completo di failover e fallback
• Ripristino di emergenza Cloud SQL per PostgreSQL: una procedura completa di failover e fallback

Architettura di disaster recovery

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

L'architettura funziona nel seguente modo:

• 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 utilizzando i dischi permanenti regionali.
• Un'istanza di Cloud SQL (la replica di lettura tra regioni) si trova 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 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 rimanga indietro 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 (RE)

Il processo di ripristino di emergenza (RE) inizia quando la regione principale diventa 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 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 RE:

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 dei client vengono riconfigurate per riprendere l'elaborazione sulla nuova istanza principale e accedere all'istanza principale in R2.

Questa procedura iniziale consente di stabilire di nuovo un database principale funzionante. Tuttavia, non consente di stabilire un'architettura di RE completa, in cui la nuova istanza principale stessa abbia un'istanza in standby e una replica di lettura tra regioni.

Una procedura di RE 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 anche un piano di riserva per il deployment originale nella regione principale originale.

Esecuzione del failover in una regione secondaria

Un processo di RE completo estende la procedura 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:

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

1. La regione principale (R1), in cui è in esecuzione 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 di standby si trova in una zona diversa dall'istanza principale. L'istanza principale ora è altamente disponibile perché è stata creata un'istanza di riserva.
6. In una terza regione (R3), viene creata e collegata all'istanza principale una nuova replica di lettura tra regioni. 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 fallback alla regione principale originale (R1) è meno complesso 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, 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 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.

Creazione 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, 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 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 i passaggi 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 creata la replica di lettura tra regioni in R1, l'istanza Cloud SQL può eseguire il fallback 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 RE 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. Se l'istanza promossa non è stata creata originariamente come replica HA, attiva l'HA sull'istanza per proteggerla da guasti zonali.
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, ripulisci l'istanza principale nella regione di RE (R2).

Ripristino di emergenza (RE) avanzato

Se utilizzi la versione Cloud SQL Enterprise Plus, puoi usufruire del RE avanzato. Questa funzionalità semplifica il recupero e il fallback dopo un failover tra regioni. Come descritto nella procedura di disaster recovery, quando esegui RE, 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 alla regione di deployment originale e recuperare la vecchia istanza principale, devi eseguire una serie di passaggi di fallback manuale.

Con il RE 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 in modo simile all'esecuzione del normale RE, tranne per il fatto che promuovi la replica di ripristino di emergenza (RE) designata. La promozione della replica RE è 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 una replica della sua replica RE (istanza B) dopo che la replica 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 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 uno switchover, non si verifica alcuna perdita di dati perché l'istanza principale (B) rimane in modalità di sola lettura finché la replica di RE designata (A) non raggiunge l'istanza principale (B). Dopo che la replica di RE (A) ha ricevuto tutti gli aggiornamenti di replica, assume il ruolo dell'istanza principale, mentre l'istanza principale precedente (B) viene riconfigurata automaticamente come replica di RE dell'istanza principale corrente (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 RE 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 switchover del RE avanzato per eseguire esercitazioni di RE di routine al fine di testare e preparare la topologia Cloud SQL per il failover tra regioni prima che si verifichi un disastro. Se si verifica un'emergenza reale, puoi eseguire il failover della replica tra regioni che hai già testato.

Replica per il ripristino di emergenza (RE)

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

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

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

• Configura la replica di RE 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 RE. Per farlo, verifica innanzitutto che la proprietà principale abbia l'HA abilitato. Quindi, effettua il passaggio alla replica di RE. Al termine dell'operazione di switchover, attiva l'alta disponibilità sulla nuova istanza principale. Dopodiché puoi tornare alla vecchia istanza principale. La replica di DR mantiene la configurazione HA anche dopo essere tornata una replica.

Failover della replica

In sintesi, un failover della replica è costituito dai seguenti eventi:

1. Creazione e assegnazione di una replica di RE.
2. La regione principale non è più disponibile.
3. Esegui il failover della replica alla replica RE.
4. L'endpoint di scrittura viene aggiornato e inizia a puntare alla nuova istanza principale.
5. Quando l'istanza principale originale viene riportata online, diventa una replica di lettura della nuova istanza principale.
6. Puoi utilizzare l'operazione di switchover per ripristinare la topologia originale del deployment.

Per visualizzare i dettagli e i diagrammi di un'operazione di failover della replica, fai clic sulle seguenti schede.

Cambia

In sintesi, un'operazione di passaggio è costituita dai seguenti eventi:

1. Creazione e assegnazione di una replica di RE.
2. Avvia un passaggio.
3. Quando il ritardo della replica si azzera, le nuove istanze principali iniziano a accettare le connessioni in entrata.
4. L'istanza principale precedente diventa una replica di lettura.
5. Se viene utilizzato un endpoint di scrittura DNS, questo viene aggiornato in modo da puntare alla nuova istanza principale.

Per visualizzare i dettagli e i diagrammi di un'operazione di passaggio, fai clic sulle seguenti schede.

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 apportare modifiche alle connessioni delle applicazioni in caso di interruzione del servizio a livello regionale.

Un endpoint di scrittura richiede che l'API Cloud DNS sia abilitata nel progetto in cui crei o hai l'istanza principale Cloud SQL Enterprise Plus esistente. Quando crei un'istanza Cloud SQL Enterprise Plus con un indirizzo IP privato 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 RE (una replica tra regioni che designi per l'istanza principale). 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 Visualizzare 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

• Utilizza il ripristino di emergenza (RE) avanzato.
• Prova il tutorial sul ripristino di emergenza Cloud SQL per MySQL.
• Esplora architetture di riferimento, diagrammi, tutorial e best practice su Google Cloud. Consulta il nostro Cloud Architecture Center.