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.
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 sono 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 dalla 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 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 sdoppio, devi assicurarti che i clienti non possano più accedere all'istanza principale originale quando R1 diventa disponibile. L'ideale è devono 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).
Passaggi successivi
- Esplora le architetture di riferimento, i diagrammi, i tutorial e le best practice su Google Cloud. Visita il nostro Cloud Architecture Center.