Questa pagina introduce il ripristino di emergenza in Cloud SQL.
Panoramica
In Google Cloud, il ripristino di emergenza (RE) dei database consiste nel fornire la continuità dell'elaborazione, in particolare quando una regione si arresta o diventa non disponibile. Cloud SQL è un servizio regionale (quando Cloud SQL è configurato per l'alta disponibilità). 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 garantiscono una transizione tra regioni configurazione del failover:
- L'accordo sul livello del servizio dell'applicazione aziendale è maggiore di regionale Accordo sul livello del servizio di Cloud SQL (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. Failover tra regioni garantisce la disponibilità continua di un database.
- Il Recovery Time Objective (RTO) e il Recovery Point Objective richiesti (RPO) sono espresse in minuti anziché in ore. Il failover su un'altra regione è più veloce rispetto alla nuova creazione di un database.
In generale, il processo di RE ha due varianti:
- Esegui il failover di un database 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 RE è particolarmente importante per i database che devono essere eseguiti nella regione principale a causa della latenza di rete o perché sono disponibili solo nella regione principale. Con questa variante, il database viene eseguito nella regione secondaria solo per la durata dell'interruzione nel regione principale.
A questo documento di RE sono associati due tutorial:- Ripristino di emergenza di Cloud SQL per MySQL: failover completo procedura di riserva
- Ripristino di emergenza di Cloud SQL per PostgreSQL: un failover completo procedura di riserva
Architettura per il ripristino di emergenza
Il seguente diagramma mostra l'architettura minima che supporta la RE del database per un'istanza Cloud SQL ad alta disponibilità:
L'architettura funziona come segue:
- Due istanze di Cloud SQL (una principale e una in standby) si trovano in due zone distinte all'interno di una singola 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 RE, la risposta tra regioni la replica di lettura è configurata in modo da sincronizzare (utilizzando la replica asincrona) con l'istanza principale utilizzando una configurazione di 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 un failover l'RPO della replica di lettura tra regioni probabilmente è diverso da zero.
Procedura di ripristino di emergenza (RE)
Il processo di ripristino di emergenza (RE) si avvia quando la regione principale 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 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 il processo di RE:
Il processo di RE prevede i seguenti passaggi:
- La regione principale (R1), che esegue l'istanza principale, diventa non disponibile.
- Il team operativo riconosce e riconosce formalmente il disastro e decide se è necessario un failover.
- Se è necessario un failover, puoi promuovere la replica di lettura tra regioni la regione secondaria (R2) come nuova istanza principale.
- Le connessioni client vengono 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 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 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.
Esegui il failover su 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 completa dell'architettura RE del database dopo il failover:
Il processo completo di RE del database prevede i seguenti passaggi:
- La regione principale (R1), che esegue il database principale, diventa non disponibile.
- Il team operativo riconosce e riconosce formalmente il disastro e decide se è necessario un failover.
- Se è necessario un failover, puoi promuovere la replica di lettura tra regioni in la regione secondaria (R2) come nuova istanza principale.
- Le connessioni client sono riconfigurate in modo da consentire l'accesso e l'elaborazione sul nuovo principale (R2).
- Una nuova istanza in standby viene creata e avviata in R2 e aggiunta al dell'istanza principale. L'istanza in standby si trova in una zona diversa da dell'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 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 del passaggio 6 implementata, la replica di lettura tra regioni può essere posizionata nella regione R1, rispetto alla regione R3. In questo caso, il codice di riserva regione (R1) è meno complessa e richiede meno passaggi.
Evitare lo stato di "split-cervello"
Un errore della regione principale (R1) non significa che la regione principale originale di Compute Engine e la sua istanza in standby vengono arrestati, rimossi automaticamente altrimenti reso inaccessibile quando R1 sarà di nuovo disponibile. Se R1 diventa i client potrebbero leggere e scrivere dati (anche per errore) sulla dell'istanza principale. 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 scomposizione, devi assicurarti che i clienti non possano più accedere all'istanza principale originale quando R1 diventa disponibile. L'ideale è dovrebbe rendere inaccessibile l'istanza principale prima che i clienti inizino a utilizzare la nuova principale, l'istanza principale originale viene eliminata subito dopo averla creata inaccessibili.
Definizione di un backup iniziale dopo il failover
Quando promuovi la replica di lettura tra regioni come nuova istanza principale in un le transazioni nella nuova istanza principale potrebbero non essere completamente sincronizzate con transazioni della società 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 noto e coerente al momento del failover. Tali backup possono essere importanti ai fini normativi o per il ripristino stato noto se i client riscontrano problemi durante l'accesso alla nuova istanza principale.
Visualizzazione della regione principale originale
Come accennato in precedenza, questo documento illustra i passaggi da seguire per regione originale (R1). Esistono due versioni diverse e il processo di sviluppo.
- 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 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é la creatività di riserva viene attivata manualmente, non in base a un'interruzione, puoi scegliere il giorno e l'ora appropriati per attività di manutenzione.
Di conseguenza, per ottenere un RE completo che abbia un'istanza principale, in standby e tra regioni di lettura, sono necessari due failover. Il primo failover viene attivato (un vero failover) e il secondo failover ripristina la configurazione iniziale un deployment (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).
- Se l'istanza promossa non è stata creata originariamente come replica ad alta disponibilità, e poi abilitare l'alta disponibilità sull'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 principali indipendenti, esegui la pulizia nell'istanza principale nella regione RE (R2).
Ripristino di emergenza avanzato
Se utilizzi Cloud SQL Enterprise Plus, puoi sfruttare della RE avanzata. Il RE avanzato semplifica il ripristino e il fallback dopo tra regioni diverse. 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 RE, per ripristinare le connessioni nella regione di deployment originale e recuperare il vecchio 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). La la promozione della replica di RE è immediata. Invece di rimuovere la vecchia istanza principale, rimane parte della replica asincrona di Cloud SQL una topologia. 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, eseguire l'ultimo passaggio del RE avanzato. Puoi restituire l'accesso a Cloud SQL allo stato originale del deployment e ripristinare la vecchia istanza principale (A) al suo ruolo precedente di istanza principale senza perdita di dati. Per eseguire questa operazione e senza alcuna perdita di dati della vecchia istanza principale (A), puoi utilizzare 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 restituite allo stato originale ruoli, ripristinando così la topologia allo stato originale prima di RE e replica di failover.
Durante RE avanzato, tutte le istanze coinvolte sia nel failover della replica mentre le operazioni di commutazione conservano gli 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.
Designata come replica per il ripristino di emergenza (RE)
Come componente obbligatorio del RE avanzato, la replica di RE ha quanto segue caratteristiche:
- Una replica RE è una replica di lettura interregionale connessa direttamente.
- Puoi modificare più volte la designazione della replica RE.
- Puoi modificare la designazione della replica RE in qualsiasi momento, tranne durante una il cambio o il failover della replica.
Inoltre, per ridurre l'RTO dopo aver utilizzato il RE avanzato, ti consigliamo di farlo le seguenti:
- Configurare la replica di RE con le stesse dimensioni dell'istanza principale.
- se l'istanza principale ha l'alta disponibilità abilitata, abilita l'alta disponibilità sulla replica RE .
Failover della replica
Un failover della replica prevede i seguenti passaggi:
- Prima di eseguire il failover della replica, hai assegnato una replica RE principale ed eventualmente testato il processo eseguendo una il cambio.
- La regione principale, in cui è in esecuzione il database principale, non disponibile.
- Il team operativo decide che è necessario un ripristino di emergenza.
- Esegui il failover della replica sulla replica di RE designata.
- La replica di RE designata tra regioni diventa l'istanza principale e inizia ad accettare letture e scritture in entrata.
- A questo punto, devi configurare le applicazioni in modo che puntino al nuovo dell'istanza principale.
- Quando la vecchia istanza principale torna disponibile, quella principale precedente diventa una replica di lettura della nuova istanza principale. Il vecchio principale conserva il proprio indirizzo IP.
Dopo aver eseguito il failover della replica, puoi ripristinare l'istanza principale la regione originale eseguendo l'operazione di cambio, invertendo la stessa replica di RE e coppia di istanze principali.
Cambia
Il cambio prevede i seguenti passaggi:
- Prima di avviare l'operazione di cambio, devi assegnare un RE replica all'istanza principale.
- Verifica che l'istanza principale sia integro. Puoi eseguire solo quando sia l'istanza principale sia la replica di RE sono online.
- Avvia il cambio. Quando avvii un cambio, l'istanza principale l'istanza smette di accettare scritture e diventa di sola lettura.
- Attendi che i log binari vengano copiati in Cloud Storage.
- La replica designata di RE raggiunge l'istanza principale.
- Quando il ritardo della replica scende a zero, la replica di RE viene promossa come nuova istanza principale. La nuova istanza principale viene avviata che accetta connessioni in entrata, incluse letture e scritture dell'applicazione.
- La vecchia istanza principale è riconfigurata come replica di lettura.
- A questo punto, devi configurare le applicazioni in modo che puntino al nuovo dell'istanza principale.
- PITR viene abilitato automaticamente per la nuova istanza principale. Il valore PITR è dopo il primo backup automatico.
Passaggi successivi
- Utilizza il ripristino di emergenza (RE) avanzato.
- Prova la 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 Cloud Architecture Center.