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 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, 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.
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:
- La regione principale (R1), in cui è in esecuzione l'istanza principale, diventa non disponibile.
- Il team operativo riconosce e conferma formalmente la catastrofe e decide se è necessario 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 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:
- La regione principale (R1), in cui è in esecuzione il database principale, diventa non disponibile.
- Il team operativo riconosce e conferma formalmente la catastrofe e decide se è necessario 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 dei client vengono riconfigurate per l'accesso e l'elaborazione sulla nuova istanza principale (R2).
- 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 standby.
- 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.
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, 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:
- 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 principali indipendenti, ripulisci l'istanza principale nella regione di RE (R2).
Repliche con struttura a cascata
Cloud SQL ti consente di creare repliche per scenari di test di ripristino di emergenza tra regioni. Puoi creare una replica con il flag cascadable-replica in una regione diversa dall'istanza principale. 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 con struttura a cascata offre due funzionalità aggiuntive rispetto alle altre repliche di lettura:
- 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 con struttura a cascata una sola volta, quindi la replica con struttura a cascata inoltra il traffico alle sue repliche all'interno della regione. Questa architettura può farti risparmiare sui costi di trasferimento di dati di rete tra regioni quando hai bisogno di più repliche in un'altra regione.
- Puoi utilizzare la replica di lettura con gerarchia come destinazione per le operazioni di switchover e failover in scenari di ripristino di emergenza tra regioni. Queste operazioni riconfigurano la replica con gerarchia per renderla l'istanza principale in un cluster.
Puoi testare il ripristino di emergenza in uno dei seguenti due modi:
- Promozione della tua replica
- Ripristino di emergenza avanzato
Ripristino di emergenza (RE) avanzato
Se utilizzi la versione Cloud SQL Enterprise Plus, puoi usufruire del RE avanzato. Il DR avanzato 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.
Per Cloud SQL per SQL Server, crea una replica di RE creando una replica tra regioni dell'istanza principale con il flag cascadable-replica. La promozione della replica 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 da puntare all'istanza 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 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 per testare e preparare la topologia Cloud SQL al 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.
- Una replica di RE è una replica a cascata che viene creata con il flag
cascadable-replica. Per fungere da replica di RE, la replica con gerarchia deve trovarsi in una regione distinta dall'istanza principale. - Non puoi avere più di una replica RE in una regione.
- 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:
- Creazione e assegnazione di una replica di RE.
- La regione principale non è più disponibile.
- Esegui il failover della replica alla replica RE.
- L'endpoint di scrittura viene aggiornato e inizia a puntare alla nuova istanza principale.
- Quando l'istanza principale originale viene riportata online, diventa una replica di lettura della nuova istanza principale.
- Puoi utilizzare l'operazione di switchover per ripristinare il deployment alla sua topology originale.
Per visualizzare i dettagli e i diagrammi di un'operazione di failover della replica, fai clic sulle seguenti schede.
Assegna replica RE
Prima di eseguire il failover della replica, devi aver assegnato una replica di RE all'istanza principale e, eventualmente, aver testato la procedura eseguendo un cambio.
Si verifica un'interruzione
La regione principale, in cui è in esecuzione il database principale, diventa non disponibile.
Failover della replica
Dopo aver stabilito che è necessario il ripristino di emergenza, esegui un failover della replica sulla replica 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 mantiene il proprio indirizzo IP.
Se la vecchia istanza principale non è attiva per 24 ore, Cloud SQL la rimuove dalla topologia di replica per garantire che il log delle transazioni sulla nuova istanza principale e sulle altre repliche non cresca in modo illimitato.
Failback all'originale
Dopo aver eseguito il failover di una replica, puoi ripristinare l'istanza principale nella regione originale eseguendo l'operazione di cambio, invertendo la stessa coppia di replica RE e istanza principale.
Cambia
In sintesi, un'operazione di passaggio è costituita dai seguenti eventi:
- Creazione e assegnazione di una replica di RE.
- Avvia un passaggio.
- Quando il ritardo della replica si azzera, le nuove istanze principali iniziano a accettare le connessioni in entrata.
- La vecchia istanza principale 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 passaggio, fai clic sulle seguenti schede.
Assegna replica RE
Prima di avviare l'operazione di *switchover*, devi assegnare una replica di RE all'istanza principale.
Verifica che l'istanza principale sia in esecuzione. Puoi eseguire un cambio solo quando sia l'istanza principale sia la replica di RE sono online.
Avvia il passaggio
Sei tu ad avviare il passaggio. Quando avvii uno switchover, la replica alla replica di RE passa alla modalità sincrona. La replica di DR si allinea all'istanza principale e imposta il relativo stato su sincronizzato. Quando il ritardo della replica si azzera, la replica RE viene promossa come nuova istanza principale. La nuova istanza principale inizia ad accettare le connessioni in entrata, incluse le letture e le scritture delle applicazioni.
Endpoint aggiornato
Dopo la promozione della replica di DR alla nuova istanza principale, l'endpoint DNS di scrittura viene aggiornato e inizia a puntare alla nuova istanza principale.
L'istanza principale precedente viene riconfigurata come replica di lettura.
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 della versione Cloud SQL Enterprise Plus, Cloud SQL genera l'endpoint di scrittura quando crei la replica di RE (una replica tra regioni creata con un flag cascadable-replica). Se l'istanza principale cambia a causa di un'operazione di switchover o 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.
- Esplora architetture di riferimento, diagrammi, tutorial e best practice su Google Cloud. Consulta il nostro Cloud Architecture Center.