Questa pagina introduce il ripristino di emergenza in Cloud SQL.
Panoramica
In Google Cloud, il ripristino di emergenza del database (RE) prevede la continuità dell'elaborazione, in particolare quando una regione presenta errori o diventa non disponibile. Cloud SQL è un servizio a livello di regione (se Cloud SQL è configurato per l'alta disponibilità). Pertanto, se la regione Google Cloud che ospita un database Cloud SQL non è più disponibile, anche il database Cloud SQL 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, in particolare 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 a livello di regione (disponibilità del 99,99% a seconda della versione di Cloud SQL in uso). Il failover di un'altra regione consente di mitigare un'interruzione.
- Tutti i livelli dell'applicazione aziendale sono già multiregionali e possono continuare a essere elaborati quando si verifica un'interruzione di una regione. La configurazione del failover tra regioni garantisce la disponibilità continua di un database.
- L'RTO (Recovery Time Objective) e il RTO (Recovery Point Objective) richiesti sono in minuti anziché in ore. Il failover su un'altra regione è più rapido rispetto alla creazione di un database di nuovo.
In generale, ci sono due varianti per il processo di RE:
- Esegui il failover di un database su una regione secondaria. Dopo che il database è pronto e utilizzato da un'applicazione, diventa il nuovo database primario e rimane il database primario.
- Un database esegue il failover su una regione secondaria, ma esegue il ripristino della regione principale dopo che la regione principale è stata recuperata dall'errore.
Questa panoramica del ripristino di emergenza dei database Google Cloud SQL descrive la seconda variante, ovvero quando un database non riuscito viene recuperato e rientra nella 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:- Ripristino di emergenza di Cloud SQL per MySQL: un processo completo di failover e fallback
- Ripristino di emergenza di Cloud SQL per PostgreSQL: un processo completo di failover e fallback
Architettura di ripristino di emergenza
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 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 mediante dischi permanenti 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 ripristino di emergenza, la replica di lettura tra regioni è configurata in modo da eseguire la sincronizzazione (utilizzando la replica asincrona) con l'istanza principale mediante 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. Quando si verifica un failover, la replica di lettura tra regioni potrebbe supportare un RPO pari a zero.
Processo di ripristino di emergenza (RE)
Il processo di ripristino di emergenza (RE) inizia quando la regione principale diventa non 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 prevede 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:
La procedura di ripristino di emergenza prevede i seguenti passaggi:
- La regione principale (R1), che esegue l'istanza principale, diventa non disponibile.
- Il team operativo riconosce e riconosce formalmente l'emergenza e decide se è necessario un failover.
- Se è richiesto un failover, puoi promuovere la replica di lettura tra regioni nella regione secondaria (R2) come 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 stabilisce di nuovo un database primario funzionante. Tuttavia, non stabilisce un'architettura di RE completa in cui la nuova istanza principale ha un'istanza in standby e una replica di lettura tra regioni.
Un processo di RE completo assicura che la singola istanza, la nuova principale, sia abilitata per l'alta disponibilità e abbia una replica di lettura tra regioni. Un processo di RE completo fornisce anche un fallback al deployment originale nella regione principale originale.
Esecuzione del failover su una regione secondaria
Un processo di RE completo estende quello di base aggiungendo passaggi per stabilire un'architettura di RE completa dopo il failover. Il seguente diagramma mostra un'architettura di RE completa del database dopo il failover:
Il processo di RE completo del database è costituito dai seguenti passaggi:
- La regione principale (R1), che esegue il database principale, diventa non disponibile.
- Il team operativo riconosce e riconosce formalmente l'emergenza e decide se è necessario un failover.
- Se è richiesto 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 l'accesso e l'elaborazione nella nuova istanza principale (R2).
- Una nuova istanza in standby viene creata, 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.
- 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 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 inserita immediatamente nella regione R1, anziché nella regione R3. In questo caso, la procedura di riserva all'area geografica principale originale (R1) è meno complessa e richiede meno passaggi.
Evitare uno stato di cervello diviso
Un errore della regione principale (R1) non significa che l'istanza principale originale e la relativa istanza in standby vengano arrestate, rimosse o rese inaccessibili automaticamente quando R1 torna a essere disponibile. Se R1 diventa disponibile, i client potrebbero leggere e scrivere dati (anche per errore) nell'istanza principale originale. In questo caso, può svilupparsi una situazione di suddivisione del cervello, in cui alcuni client accedono a dati inattivi nel database primario precedente, mentre altri client accedono a dati aggiornati nel nuovo database principale, causando problemi all'attività.
Per evitare una situazione di coordinamento, 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 clienti inizino a utilizzare la nuova istanza principale, poi eliminare quella principale subito dopo averla resa inaccessibile.
Definizione di un backup iniziale dopo il failover
Quando promuovi la replica di lettura tra regioni come nuova 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 punto del failover. Questi backup possono essere importanti per scopi normativi o per il ripristino a uno stato noto se i client riscontrano problemi durante l'accesso alla nuova istanza principale.
Verrà utilizzata la regione principale originale
Come descritto in precedenza, questo documento illustra i passaggi per tornare alla regione 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 aggiuntiva in R1.
Se esiste la replica di lettura tra regioni in R1, l'istanza Cloud SQL può ricorrere a R1. Poiché questa funzionalità di riserva viene attivata manualmente e non basata 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 primaria, in standby e tra regioni, sono necessari due failover. Il primo failover viene attivato dall'interruzione (un vero failover) e il secondo ristabilita il deployment iniziale (un fallback di riserva).
La procedura di riserva alla regione principale originale (R1) prevede i seguenti passaggi:
- Promuovi la replica tra regioni appena creata nella regione principale originale (R1).
- Se l'istanza sponsorizzata non è stata originariamente creata come replica ad alta disponibilità, abilita l'alta disponibilità nell'istanza per la protezione da errori a livello di zona.
- 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 principale nella regione di RE (R2).
Ripristino di emergenza avanzato (RE)
Se utilizzi la versione Cloud SQL Enterprise Plus, puoi sfruttare il RE avanzato. Il ripristino di emergenza avanzato semplifica il recupero 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 con errori dell'istanza principale precedente e la regione operativa della nuova istanza principale. Con RE, per ripristinare le connessioni alla regione di deployment originale e ripristinare l'istanza principale precedente, devi eseguire una serie di passaggi di fallback manuali.
Con il 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 del normale RE, con la differenza che promuovi la replica designata per il ripristino di emergenza (RE). La promozione della replica di RE è immediata. Anziché rimuovere l'istanza principale precedente, l'istanza rimane una 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 la replica di RE è stata promossa alla nuova istanza principale.
Dopo che l'istanza principale precedente (A) è stata trasformata in una replica, puoi eseguire il passaggio finale del RE avanzato. Puoi ripristinare lo stato originale del deployment Cloud SQL e ripristinare il ruolo precedente dell'istanza principale (A) come istanza principale senza alcuna perdita di dati. Per eseguire questo ripristino senza perdita di dati dell'istanza principale precedente (A), puoi utilizzare l'operazione di commutazione. Quando esegui un passaggio, 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 della replica, la replica di RE (A) assume il ruolo dell'istanza principale, mentre l'istanza principale precedente (B) viene riconfigurata automaticamente come replica di RE dell'istanza principale attuale (A). Le istanze vengono restituite ai ruoli originali, ripristinando così lo stato originale della topologia prima del failover di RE e replica.
Durante il RE avanzato, tutte le istanze coinvolte nelle operazioni di failover di replica e di passaggio mantengono i propri indirizzi IP.
Puoi anche utilizzare l'operazione di passaggio del RE avanzato per eseguire i drill di RE di routine per testare e preparare la tua topologia Cloud SQL per il failover tra regioni prima che si verifichi un'emergenza. In caso di emergenza reale, puoi eseguire il failover della replica tra regioni che hai già testato.
Replica designata per il ripristino di emergenza (RE)
Come componente obbligatorio del RE avanzato, la replica di RE ha le seguenti caratteristiche:
- Una replica di RE è una replica di lettura tra regioni connessa direttamente.
- Puoi modificare più volte la designazione della replica di RE.
- Puoi modificare la designazione della replica di RE in qualsiasi momento, tranne durante un'operazione di failover o di passaggio a replica.
Inoltre, per ridurre l'RTO dopo aver utilizzato il RE avanzato, ti consigliamo di procedere come segue:
- Configura la replica di RE con le stesse dimensioni dell'istanza principale.
- Se per l'istanza principale è abilitata l'alta disponibilità, abilita l'alta disponibilità anche nella replica di RE.
Failover della replica
Il failover di una replica prevede i seguenti passaggi:
- Prima di eseguire un failover di replica, hai assegnato una replica di RE all'istanza principale e potresti aver testato il processo eseguendo uno switch.
- La regione principale, che esegue il database primario, diventa non disponibile.
- Il team operativo decide che è necessario eseguire il ripristino di emergenza.
- Esegui un failover di replica alla replica di RE designata.
- La replica di RE designata tra regioni diventa immediatamente l'istanza principale e inizia ad accettare le letture e le scritture in entrata.
- Al momento, devi configurare le applicazioni in modo che puntino alla nuova istanza principale.
- Quando l'istanza principale precedente diventa di nuovo disponibile, quella principale diventa una replica di lettura della nuova istanza principale. L'istanza principale precedente conserva il proprio indirizzo IP.
Dopo aver eseguito un failover di replica, puoi ripristinare l'istanza principale nella regione originale eseguendo l'operazione di commutazione, invertendo la stessa replica di RE e la stessa coppia di istanze principali.
Cambia
Il passaggio prevede i seguenti passaggi:
- Prima di avviare l'operazione di commutazione, devi assegnare una replica di RE all'istanza principale.
- Verifica che l'istanza principale sia integro. Puoi eseguire una migrazione solo quando sia l'istanza principale sia la replica di RE sono online.
- Avvia il passaggio. Quando avvii una transizione, l'istanza principale smette di accettare operazioni di scrittura e diventa di sola lettura.
- Attendi che i log binari vengano copiati in Cloud Storage.
- La replica di RE designata raggiunge l'istanza principale.
- Quando il ritardo di 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 operazioni di lettura e scrittura dell'applicazione.
- L'istanza principale precedente viene riconfigurata come replica di lettura.
- Al momento, devi configurare le applicazioni in modo che puntino alla nuova istanza principale.
- Il PITR viene abilitato automaticamente per la nuova istanza principale. Il PITR è possibile solo dopo il primo backup automatico.
Passaggi successivi
- Utilizza il ripristino di emergenza avanzato (RE).
- Prova il tutorial sul ripristino di emergenza di Cloud SQL per MySQL.
- Esplora le architetture di riferimento, i diagrammi, i tutorial e le best practice su Google Cloud. Visita il nostro Centro architetture Cloud.