Questa pagina introduce ripristino di emergenza in Cloud SQL.
Panoramica
In Google Cloud, il ripristino di emergenza (RE) del database è un processo che garantisce 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 affidabilità (HA)). Pertanto, se la regione Google Cloud che ospita un database Cloud SQL non è disponibile, anche il database Cloud SQL non è disponibile.
Per continuare l'elaborazione, devi rendere disponibile il database in una regione secondaria il prima possibile. Il piano di DR 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 giustificano 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% a seconda della versione di Cloud SQL). Eseguendo il failover in un'altra regione, puoi mitigare un'interruzione.
- Tutti i livelli dell'applicazione aziendale sono già multiregionali e possono continuare l'elaborazione quando si verifica un'interruzione in una regione. La configurazione del failover tra regioni contribuisce a supportare la disponibilità continua di un database.
- Il Recovery Time Objective (RTO) e il Recovery Point Objective (RPO) richiesti sono espressi 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 primario e rimane tale.
- Un database esegue il failover in una regione secondaria, ma torna alla regione principale dopo che quest'ultima è stata recuperata dall'errore.
Questa panoramica ripristino di emergenza del database Google Cloud SQL descrive la seconda variante, ovvero quando un database con errori viene recuperato e torna alla regione principale. Questa variante del processo di DR è particolarmente rilevante 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.
Architettura del disaster recovery
Il seguente diagramma mostra l'architettura minima che supporta il RE del database per un'istanza Cloud SQL ad alta affidabilità:
L'architettura funziona nel seguente modo:
- 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 utilizzando i Persistent Disk a livello di regione.
- Un'istanza di Cloud SQL (la replica di lettura tra regioni) si trova in una seconda regione (la regione secondaria). Per il DR, la replica di lettura tra regioni è configurata per la sincronizzazione (utilizzando la replica asincrona) con l'istanza principale utilizzando una configurazione della replica di lettura.
Le istanze primarie e in standby condividono lo stesso disco a livello di regione, pertanto 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 non è pari a zero.
Processo di disaster recovery (RE)
Il processo di ripristino di emergenza (RE) inizia 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 DR definisce i passaggi operativi da eseguire, manualmente o automaticamente, per mitigare l'errore della regione e stabilire un'istanza primaria in esecuzione in una regione secondaria.
Il seguente diagramma mostra il processo di RE:
Il processo di DR prevede i seguenti passaggi:
- La regione principale (R1), in cui è in esecuzione l'istanza principale, diventa non disponibile.
- Il team operativo riconosce e conferma formalmente l'emergenza e decide se è necessario eseguire un failover.
- Se è necessario un failover, puoi promuovere la replica di lettura tra regioni nella regione secondaria (R2) in modo che diventi la nuova istanza principale.
- Le connessioni client vengono riconfigurate per riprendere l'elaborazione sulla nuova istanza principale e accedere all'istanza principale in R2.
Questo processo iniziale ristabilisce un database primario funzionante. Tuttavia, non consente di creare un'architettura di RE completa in cui la nuova istanza primaria disponga di un'istanza in standby e di una replica di lettura tra regioni.
Un processo di RE completo garantisce che l'istanza singola, la nuova istanza principale, sia abilitata per l'alta affidabilità e disponga di una replica di lettura tra regioni. Un processo di RE completo prevede anche un fallback al deployment originale nella regione principale originale.
Failover in una regione secondaria
Un processo di RE completo implica l'aggiunta di passaggi al processo di RE di base per stabilire un'architettura di RE completa dopo l'esecuzione di un failover. Il seguente diagramma mostra un'architettura di RE del database completo dopo il failover:
Il processo di RE del database completo prevede i seguenti passaggi:
- La regione con istanza primaria (R1), in cui è in esecuzione il database primario, diventa non disponibile.
- Il team operativo riconosce e conferma formalmente l'emergenza e decide se è necessario eseguire un failover.
- Se è necessario un failover, puoi promuovere la replica di lettura tra regioni nella regione secondaria (R2) in modo che diventi la nuova istanza principale.
- Le connessioni client vengono riconfigurate per accedere ed elaborare sulla nuova istanza principale (R2).
- Viene creata e avviata una nuova istanza in standby in R2, che viene aggiunta all'istanza primaria. L'istanza in standby si trova in una zona diversa rispetto all'istanza primaria. L'istanza principale è ora ad alta affidabilità perché è stata creata un'istanza in standby.
- In una terza regione (R3), viene creata una nuova replica di lettura tra regioni, che viene collegata all'istanza principale. A questo punto, un'architettura di disaster recovery completa viene ricreata e resa 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 fallback alla regione dell'istanza primaria originale (R1) è meno complesso e richiede meno passaggi.
Evitare uno stato di split-brain
Un errore della regione principale (R1) non significa che l'istanza principale originale e la relativa istanza in standby vengano automaticamente arrestate, rimosse o rese inaccessibili quando R1 torna 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 primario, mentre altri accedono a dati aggiornati nel nuovo database primario, causando problemi alla tua attività.
Per evitare una situazione di split-brain, devi assicurarti che i client non possano più accedere all'istanza primaria 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 eliminarla subito dopo averla resa inaccessibile.
Creazione di un backup iniziale dopo il failover
Quando promuovi la replica di lettura tra regioni in modo che diventi la 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 coerente e noto al momento del failover. Questi backup possono essere importanti per scopi normativi o per il ripristino di uno stato noto se i client riscontrano problemi durante l'accesso alla nuova istanza primaria.
Failback alla regione principale originale
Come descritto in precedenza, questo documento fornisce i passaggi per eseguire il fallback alla regione originale (R1). Esistono due versioni diverse 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 aggiuntiva in R1.
Una volta creata la replica di lettura tra regioni in R1, l'istanza Cloud SQL può eseguire il fallback in R1. Poiché questo fallback 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 un'istanza principale, una in standby e una replica di lettura tra regioni, sono necessari due failover. Il primo failover viene attivato dall'interruzione (un failover vero e proprio), mentre il secondo failover ristabilisce il deployment iniziale (un fallback).
Il fallback alla regione principale originale (R1) prevede i seguenti passaggi:
- Promuovi la replica tra regioni appena creata nella regione principale originale (R1).
- Riconfigura le applicazioni in modo che si connettano alla nuova istanza principale.
- Crea una replica tra regioni per la nuova istanza principale nella regione di RE (R2).
- (Facoltativo) Per evitare di eseguire più istanze primarie indipendenti, esegui la pulizia dell'istanza primaria nella regione di RE (R2).
Repliche a cascata
Cloud SQL consente di creare repliche per scenari di test e ripristino di emergenza tra regioni. Puoi creare una replica con il flag cascadable-replica in una regione diversa da quella dell'istanza principale. Se si verifica un'emergenza nella regione dell'istanza principale, avvia il failover alla replica a cascata.
Dopo che l'istanza principale originale torna online e agisce come replica
integra, puoi utilizzare l'operazione di switchover per tornare all'istanza principale
originale.
Una replica a cascata ha due funzionalità aggiuntive che altre repliche di lettura non hanno:
- Puoi collegare altre repliche di lettura (repliche a cascata) alla replica di lettura con possibilità di replica a cascata. Cloud SQL invia il traffico di replica tra regioni alla replica a cascata una sola volta, dopodiché la replica a cascata inoltra il traffico alle repliche nella regione. Questa architettura può ridurre i costi di trasferimento di dati di rete tra regioni quando devi avere più repliche in un'altra regione.
- Puoi utilizzare la replica di lettura con possibilità di replica a cascata come destinazione per le operazioni di switchover e failover in scenari di ripristino di emergenza tra regioni. Queste operazioni riconfigurano la replica a cascata in modo che diventi l'istanza principale di un cluster.
Puoi testare ripristino di emergenza in uno dei due modi seguenti:
- Promozione della replica
- Disaster recovery avanzato
Ripristino di emergenza (RE) avanzato
Se utilizzi la versione Cloud SQL Enterprise Plus, puoi usufruire del RE avanzato, che semplifica il ripristino e il fallback dopo un failover tra regioni. Come descritto nella sezione Processo di disaster recovery, 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 alla regione di deployment originale e riottenere la vecchia istanza principale, devi eseguire una serie di passaggi di fallback manuali.
Con RE avanzato, quando si verifica un errore in una regione, puoi richiamare un failover della replica.
Con il failover della replica, promuovi una replica di lettura tra regioni in modo simile all'esecuzione di RE regolare, con la differenza che promuovi la replica di ripristino di emergenza (RE) designata.
Per Cloud SQL per SQL Server, crei una replica di RE 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 si risolve nell'indirizzo IP dell'istanza principale.
Quando la replica di RE viene promossa, l'endpoint di scrittura viene aggiornato in modo da puntare all'istanza principale appena promossa. In questo modo, tutte le applicazioni che tentano di connettersi utilizzando l'endpoint di scrittura vengono reindirizzate all'istanza promossa.
Anziché essere rimossa, l'istanza principale precedente rimane parte della topologia di replica asincrona di Cloud SQL. L'istanza principale precedente (istanza A) diventa una replica della sua replica di RE (istanza B) dopo che quest'ultima è stata promossa a nuova istanza principale.
Dopo che la vecchia istanza principale (A) è stata trasformata in una replica, puoi eseguire il passaggio finale del RE avanzato. Puoi riportare il deployment Cloud SQL allo stato originale e ripristinare il ruolo precedente della vecchia istanza principale (A) 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 switchover. Quando esegui un cambio, non si verifica alcuna perdita di dati perché l'istanza principale (B) rimane in modalità di sola lettura finché la replica RE designata (A) non raggiunge l'istanza principale (B). Dopo che la replica di RE (A) ha ricevuto tutti gli aggiornamenti della replica, assume il ruolo di 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 ruoli originali, ripristinando così la topologia allo stato originale prima RE e del failover della replica.
Durante RE avanzato, tutte le istanze coinvolte nelle operazioni di failover e switchover della replica mantengono i propri indirizzi IP.
Puoi anche utilizzare l'operazione di switchover del RE avanzato per eseguire esercitazioni di RE di routine per testare e preparare la topologia Cloud SQL per il failover tra regioni prima che si verifichi un disaster recovery. Se si verifica un'emergenza effettiva, puoi eseguire il failover della replica tra regioni che hai già testato.
Replica per disaster recovery (RE)
In quanto componente obbligatorio del RE avanzato, la replica RE ha le seguenti caratteristiche:
- Una replica di RE è una replica di lettura tra regioni direttamente connessa.
- Puoi modificare la designazione della replica di RE più volte.
- Una replica RE è una replica a cascata, che crei con il flag
cascadable-replica. Per fungere da replica di RE, la replica a cascata deve trovarsi in una regione separata dall'istanza principale. - Non puoi avere più di una replica di RE in una regione.
- Puoi modificare l'assegnazione della replica di RE in qualsiasi momento, tranne durante un'operazione di switchover o failover della replica.
Inoltre, per ridurre l'RTO dopo aver utilizzato 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 abilitata, ti consigliamo di abilitarla anche sulla replica di RE. Per farlo, innanzitutto verifica che l'HA sia abilitata per l'istanza principale. Poi, esegui il cambio alla replica di RE. Al termine dell'operazione di switchover, attiva l'alta affidabilità sulla nuova istanza principale. Poi puoi tornare all'istanza principale precedente. La replica DR mantiene la configurazione HA anche dopo essere tornata a essere una replica.
Failover della replica
In sintesi, un failover della replica è costituito dai seguenti eventi:
- Crei e assegni una replica di RE.
- La regione principale diventa non disponibile.
- Esegui il failover della replica nella replica RE.
- L'endpoint di scrittura viene aggiornato e inizia a puntare alla nuova istanza principale.
- Quando l'istanza principale originale torna online, diventa una replica di lettura della nuova istanza principale.
- Puoi utilizzare l'operazione di switchover per ripristinare il deployment nella topologia originale.
Per visualizzare i dettagli e i diagrammi di un'operazione di failover della replica, fai clic sulle seguenti schede.
Assegna replica DR
Prima di eseguire un failover della replica, hai assegnato una replica di RE all'istanza principale e, se possibile, hai testato il processo eseguendo un cambio.
Si verifica un'interruzione
La regione principale, in cui è in esecuzione il database primario, diventa non disponibile.
Failover della replica
Dopo aver stabilito che è necessario il ripristino di emergenza, esegui un failover della replica sulla replica di RE.
La replica di RE diventa immediatamente l'istanza principale e inizia ad accettare letture e scritture in entrata. L'endpoint di scrittura viene aggiornato e inizia a puntare alla nuova istanza principale.
L'istanza principale originale diventa una replica
Dopo la promozione della replica, Cloud SQL controlla periodicamente se l'istanza principale originale è di nuovo online. Se l'istanza principale originale è online, Cloud SQL ricrea l'istanza principale precedente come replica dell'istanza promossa. La vecchia istanza principale conserva il proprio indirizzo IP.
Se l'istanza principale precedente non è attiva per 24 ore, Cloud SQL la rimuove dalla topologia di replica per garantire che il log delle transazioni nell'istanza principale nuova e nelle altre repliche non cresca senza limiti.
Failback all'originale
Dopo aver eseguito un failover della replica, puoi ripristinare l'istanza principale nella regione originale eseguendo l'operazione di switchover, invertendo la stessa coppia di replica RE e istanza principale.
Cambia
In sintesi, un'operazione di switchover è costituita dai seguenti eventi:
- Crei e assegni una replica di RE.
- Avvii uno switchover.
- Quando il ritardo di replica scende a zero, le nuove istanze principali iniziano ad accettare le connessioni in entrata.
- L'istanza principale precedente diventa una replica di lettura.
- 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 switchover, fai clic sulle seguenti schede.
Assegna replica DR
Prima di avviare l'operazione di *switchover*, devi assegnare una replica RE all'istanza principale.
Verifica che l'istanza principale sia integra. Puoi eseguire un switchover solo quando sia l'istanza principale sia la replica RE sono online.
Avvia switchover
Sei tu ad avviare lo switchover. Quando avvii uno switchover, la replica nella replica di RE passa alla modalità sincrona. La replica di DR si aggiorna in base all'istanza principale e cambia lo stato in Sincronizzata. 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 le connessioni in entrata, incluse le letture e le scritture dell'applicazione.
Endpoint aggiornato
Dopo la promozione della replica DR alla nuova istanza principale, l'endpoint di scrittura DNS viene aggiornato e inizia a puntare alla nuova istanza principale.
L'istanza principale precedente viene riconfigurata come replica di lettura.
Endpoint di scrittura
Un endpoint di scrittura è un nome DNS (Domain Name Service) globale che si risolve automaticamente nell'indirizzo IP dell'istanza principale attuale. Questo endpoint reindirizza automaticamente le connessioni in entrata alla nuova istanza principale in caso di operazione di failover o switchover della replica. Puoi utilizzare l'endpoint di scrittura in una stringa di connessione SQL anziché un indirizzo IP. Utilizzando un endpoint di scrittura, puoi evitare di dover apportare modifiche alla connessione dell'applicazione quando si verifica un'interruzione della regione.
Un endpoint di scrittura richiede che l'API Cloud DNS sia abilitata nel progetto in cui crei o hai l'istanza principale di 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 crei 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 quest'ultima diventa la nuova istanza principale.
Per saperne di più sull'utilizzo di un endpoint di scrittura per connetterti a un'istanza, consulta Connettiti a un'istanza utilizzando un endpoint di scrittura.
Passaggi successivi
- Utilizza il ripristino di emergenza (RE) avanzato.
- Esplora architetture di riferimento, diagrammi, tutorial e best practice su Google Cloud. Consulta il nostro Cloud Architecture Center.