Ripristino di emergenza di Cloud SQL per MySQL: un processo completo di failover e fallback

Questo tutorial descrive un failover e un fallback completo per il ripristino di emergenza (RE) in Cloud SQL per MySQL utilizzando repliche di lettura tra regioni.

In questo tutorial, configurerai un servizio Cloud SQL per MySQL ad alta disponibilità (HA) per il RE e simulare un'interruzione. Quindi segui il processo di RE per ripristinare il deployment iniziale dopo la risoluzione dell'interruzione.

Questo tutorial è destinato ad architetti di database, amministratori e ingegneristici.

Per leggere una panoramica del funzionamento del ripristino di emergenza SQL, vedi Informazioni sul ripristino di emergenza in Cloud SQL.

Obiettivi

  • Crea un'istanza Cloud SQL per MySQL ad alta disponibilità.
  • Esegui il deployment di una replica di lettura tra regioni su Google Cloud utilizzando Cloud SQL per MySQL.
  • Simula un'emergenza e un failover con Cloud SQL per MySQL.
  • Comprendi i passaggi per recuperare il deployment iniziale utilizzando un di riserva con Cloud SQL per MySQL.

Questo documento è incentrato solo sui processi di failover e di fallback RE tra regioni. Per informazioni su un processo di failover ad alta disponibilità in una singola regione, consulta Panoramica della configurazione ad alta disponibilità.

Costi

In questo documento utilizzi i seguenti componenti fatturabili di Google Cloud:

Per generare una stima dei costi in base all'utilizzo previsto, utilizza il Calcolatore prezzi. I nuovi utenti di Google Cloud potrebbero essere idonei per una prova gratuita.

Una volta completate le attività descritte in questo documento, puoi evitare la fatturazione continua eliminando le risorse che hai creato. Per ulteriori informazioni, consulta la pagina Pulizia.

Prima di iniziare

  1. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  2. Assicurati che la fatturazione sia attivata per il tuo progetto Google Cloud.

  3. In the Google Cloud console, activate Cloud Shell.

    Activate Cloud Shell

Fase 1: configurazione di un'istanza di database ad alta disponibilità per RE

Le fasi seguenti (1-3) ti guidano in una procedura di failover e di riserva completa e il processo di sviluppo. Esegui tutti i comandi utilizzando il comando gcloud in in Cloud Shell. Per semplificare la procedura, il tutorial utilizza le impostazioni predefinite quando (ad esempio la versione predefinita di Cloud SQL). Nel tuo di produzione, potresti aggiungere altre configurazioni.

Imposta le variabili di ambiente

Questa sezione fornisce esempi di variabili di ambiente che definiscono i vari i nomi e le regioni richiesti per i comandi che esegui in questo tutorial di Google Cloud. Puoi modificare queste variabili di esempio in base alle tue esigenze.

Le tabelle seguenti descrivono i nomi delle istanze, i relativi ruoli e il deployment regioni per ogni fase del processo di RE e fallback in questo tutorial. Puoi inserisci anche i tuoi nomi e le tue regioni.

Fase iniziale
Nome istanza Role Regione
instance-1 Principale us-west1
instance-2 Standby us-west1
instance-3 Replica di lettura tra regioni us-west2
Fase di emergenza
Nome istanza Role Regione
instance-3 Principale us-west2
instance-4 Standby us-west2
instance-5 Replica di lettura tra regioni us-west3
instance-6 Replica di lettura tra regioni us-west1
Fase di riserva (finale)
Nome istanza Role Regione
instance-6 Principale us-west1
instance-7 Standby us-west1
instance-8 Replica di lettura tra regioni us-west2

I nomi delle istanze nelle tabelle precedenti non sono codificati con i relativi ruoli. In un Situazione di RE, la funzione di un'istanza potrebbe cambiare, ad esempio potrebbe diventare quella principale. Se il nome della nuova istanza principale contiene con la parola replica, potrebbero sorgere confusione e conflitti. Pertanto, consigliamo di non codifica i nomi delle istanze con la funzione o il ruolo che eseguono.

Le tabelle precedenti elencano i nomi delle istanze in standby. Anche se questo tutorial non esercita un failover ad alta disponibilità, include i nomi di istanze in standby per completezza.

La fase di fallback ricrea il deployment originale della fase iniziale le stesse regioni originali. Tuttavia, in un fallback, i nomi delle istanze devono cambiare perché i nomi originali non sono immediatamente disponibili anche dopo viene eliminata l'istanza originale. Per supportare la creazione rapida di istanze in la fase di fallback, dovresti usare nomi delle istanze che non corrispondono utilizzata nella fase iniziale.

  • In Cloud Shell, imposta le variabili di ambiente basate su specifiche nelle tabelle precedenti:

    export primary_name=instance-1
export primary_tier=db-n1-standard-2
export primary_region=us-west1
export primary_root_password=my-root-password
export primary_backup_start_time=22:00
export cross_region_replica_name=instance-3
export cross_region_replica_region=us-west2

    Se vuoi utilizzare un livello diverso per l'istanza principale, elenca disponibili e assegnare un valore diverso primary_tier:

    gcloud sql tiers list

    Per un elenco di regioni in cui puoi eseguire il deployment di Cloud SQL, consulta Impostazioni istanza.

Crea un'istanza di database principale

  1. In Cloud Shell, crea una singola istanza di Cloud SQL:

    gcloud sql instances create $primary_name \
    --tier=$primary_tier \
    --region=$primary_region

    Il comando gcloud viene messo in pausa fino alla creazione dell'istanza.

  2. Imposta la password root:

    gcloud sql users set-password root \
    --host=% \
    --instance $primary_name \
    --password $primary_root_password

crea un database primario

  1. In Cloud Shell, accedi alla shell MySQL e inserisci il nome alla richiesta:

    gcloud sql connect $primary_name --user=root

  2. Al prompt MySQL, Crea un database e carica i dati di test:

    CREATE DATABASE guestbook;

USE guestbook;

CREATE TABLE entries (guestName VARCHAR(255), content VARCHAR(255), entryID INT NOT NULL AUTO_INCREMENT, PRIMARY KEY(entryID));

INSERT INTO entries (guestName, content) values ("first guest", "I got here!");
INSERT INTO entries (guestName, content) values ("second guest", "Me too!");

  3. Verifica che il commit dei dati sia stato eseguito correttamente:

    SELECT * FROM entries;

    Verifica che vengano restituite due righe di dati.

  4. Esci dalla shell MySQL:

    exit;

A questo punto, hai un singolo database che include una tabella e alcuni e i dati di Google Cloud.

Cambia l'istanza principale in un'istanza di database ad alta disponibilità

Puoi configurare Cloud SQL solo come sistema ad alta disponibilità a livello di regione, non come tra regioni diverse. (la configurazione di una replica di lettura tra regioni è diversa da configurando Cloud SQL come sistema interregionale). Per ulteriori informazioni le informazioni, vedi Abilitazione e disattivazione dell'alta disponibilità su un'istanza.

  • In Cloud Shell, crea un'istanza Cloud SQL abilitata ad alta disponibilità:

    gcloud sql instances patch $primary_name \
    --availability-type REGIONAL \
    --enable-bin-log \
    --backup-start-time=$primary_backup_start_time

Aggiungi una replica di lettura tra regioni per RE con aggiornamento automatico

I passaggi seguenti sono sufficienti per creare una replica di lettura tra regioni questo tutorial:

  1. In Cloud Shell, configura una replica di lettura tra regioni:

    gcloud sql instances create $cross_region_replica_name \
    --master-instance-name=$primary_name \
    --region=$cross_region_replica_region

  2. (Facoltativo) Per verificare che il database sia stato replicato, nella sezione Nella console Google Cloud, vai alla pagina Istanze di Cloud SQL.

    Vai a Istanze

    La pagina Istanze mostra i cluster principali e replica.

    La console Google Cloud mostra che l'istanza principale (instance-1) è abilitato per l'alta disponibilità e che una replica di lettura tra regioni (instance-3) esiste.

  3. Utilizzando la stessa password root per l'istanza principale, accedi all'account tra regioni replica di lettura:

    gcloud sql connect $cross_region_replica_name --user=root

  4. Al prompt di MySQL, seleziona i dati per assicurarti che la replica funzioni:

    USE guestbook;

SELECT * FROM entries;

  5. Esci dalla shell MySQL:

    exit;

Per maggiori dettagli su come configurare una replica di lettura completa tra regioni, consulta Documentazione di Cloud SQL

Per database di grandi dimensioni in un ambiente di produzione, consigliamo di eseguire il backup dal database principale e crea la replica di lettura tra regioni dal backup. Questo passaggio consente di ridurre il tempo necessario per la sincronizzazione della replica di lettura con il database principale. Questa procedura è descritta nella sezione successiva. Tuttavia, puoi scegliere di saltare questo passaggio e continuare con Fase 2.

Aggiungi una replica di lettura tra regioni basata su un file di dump

Un modo per ottimizzare la creazione di una replica di lettura tra regioni è sincronizza la replica da uno stato precedente e coerente del database primario invece di sincronizzarsi al momento di accedere alla nuova istanza principale. Questo dell'ottimizzazione richiede la creazione di un file di dump che la replica utilizzi come punto di stato.

Per i passaggi per creare una replica basata su un file di dump, vedi Replica da un server esterno a Cloud SQL (v1.1). Questo approccio può essere utile per database di produzione di grandi dimensioni. Tuttavia, questo il tutorial salta questo passaggio perché il set di dati di test è abbastanza piccolo per la replica dei dati.

Fase 2: simulazione di un'emergenza (interruzione nella regione)

In questa fase, simulerai l'interruzione di una regione principale in un ambiente di produzione rendendo non disponibile il database principale.

Controlla il ritardo della replica di lettura tra regioni

Nei passaggi seguenti, determinerai il ritardo della replica tra regioni replica di lettura:

  1. Nella console Google Cloud, vai a Cloud SQL Istanze.

    Vai a Istanze

  2. Fai clic sulla replica di lettura (instance-3).

  3. Nell'elenco a discesa delle metriche, fai clic su Ritardo della replica:

    L'elenco a discesa delle metriche mostra varie opzioni, tra cui Replica Ritardo.

    La metrica cambia in Ritardo della replica. Il grafico non mostra alcun ritardo:

    Il grafico Ritardo della replica presenta opzioni di visualizzazione che vanno da un'ora a 30 giorni.

Idealmente, il ritardo della replica è pari a zero quando si verifica un'interruzione della regione principale, pari a zero garantisce che tutte le transazioni vengano replicate. Se non è zero, alcune transazioni potrebbero non essere replicate. In questo caso, i valori interregionali la replica non conterrà tutte le transazioni impegnate nell'istanza principale.

Rendi non disponibile l'istanza principale

Nei passaggi seguenti, simulerai un'emergenza arrestando quella principale. Se tra regioni è collegata all'istanza principale, devi prima scollegare altrimenti non potrai arrestare l'istanza Cloud SQL.

  1. In Cloud Shell, rimuovi la replica di lettura tra regioni principale:

    gcloud sql instances patch $cross_region_replica_name \
    --no-enable-database-replication

    Quando ti viene richiesto, accetta l'opzione per continuare.

  2. Arresta l'istanza del database principale:

    gcloud sql instances patch $primary_name --activation-policy NEVER

Implementazione di RE

  1. In Cloud Shell, promuovi la replica di lettura tra regioni istanza autonoma:

    gcloud sql instances promote-replica $cross_region_replica_name

    Quando ti viene richiesto, accetta l'opzione per continuare. Cloud SQL La pagina Istanze mostra la precedente replica di lettura tra regioni (instance-3) come nuova principale e quella precedente (instance-1) come interrotto:

    La pagina Istanze mostra lo stato di due istanze, quella principale e quella principale.

    Dopo aver promosso la replica di lettura tra regioni come nuova istanza principale, per l'alta disponibilità. Come best practice, dovresti aggiornare l'ambiente con una denominazione corretta.

  2. Aggiorna le variabili di ambiente:

    export former_primary_name=$primary_name
export primary_name=$cross_region_replica_name
export primary_tier=db-n1-standard-2
export primary_region=$cross_region_replica_region
export primary_root_password=my-root-password
export primary_backup_start_time=22:00
export cross_region_replica_name=instance-5
export cross_region_replica_region=us-west3

  3. Avvia la nuova istanza principale:

    gcloud sql instances patch $primary_name --activation-policy ALWAYS

  4. Abilita la nuova istanza principale come istanza a livello di regione ad alta disponibilità:

    gcloud sql instances patch $primary_name \
    --availability-type REGIONAL \
    --enable-bin-log \
    --backup-start-time=$backup_start_time

  5. Crea una replica di lettura tra regioni in una terza regione:

    gcloud sql instances create $cross_region_replica_name \
    --master-instance-name=$primary_name \
    --region=$cross_region_replica_region

    In un passaggio precedente, hai impostato cross_region_replica_region variabile di ambiente in us-west3.

    Al termine del failover, le istanze di Cloud SQL della console Google Cloud mostra che il nuovo (instance-3) è abilitato come alta disponibilità e ha una replica di lettura tra regioni (instance-5):

    La pagina Istanze mostra la nuova istanza principale abilitata per l'alta disponibilità e una nuova replica.

  6. (Facoltativo) Se disponi di backup regolari, segui le procedura descritta in precedenza per sincronizzare la nuova istanza principale con la versione del backup più recente.

  7. (Facoltativo) Se utilizzi un proxy Cloud SQL, configura il proxy a utilizzare la nuova istanza principale per riprendere l'elaborazione della richiesta.

Gestire un'interruzione di breve durata in una regione

È possibile che l'interruzione che attiva un failover venga risolta prima che il failover è stato completato. In questo caso, potrebbe essere opportuno annullare il failover e continuare a utilizzare l'istanza Cloud SQL principale originale la regione in cui si è verificata l'interruzione.

A seconda dello stato specifico del processo di failover, il traffico tra regioni replica potrebbe essere già stata promossa. In questo caso, devi eliminarla e ricrea una replica di lettura tra regioni.

Elimina l'istanza principale originale per evitare una situazione di spaccatura

Per evitare di incorrere in situazioni di scomposizione, devi eliminare l'elemento principale originale (o non sono accessibili ai client del database).

Dopo un failover, può verificarsi una situazione di "split-brain" quando i client scrivono contemporaneamente al nuovo database primario originale. In questo del caso, i contenuti dei due database non sono coerenti. Dopo un failover, il database principale originale è obsoleto e non deve ricevere operazioni di lettura o scrittura per via del traffico.

  • In Cloud Shell, elimina l'istanza principale originale:

    gcloud sql instances delete $former_primary_name

    Quando ti viene richiesto, accetta l'opzione per continuare.

    Nella console Google Cloud, vai alla pagina Istanze di Cloud SQL non mostra più l'istanza principale originale (instance-1) come parte di del deployment:

    La pagina Istanze mostra solo la nuova replica principale e la replica di lettura.

Fase 3: implementazione di una creatività di riserva

Per implementare un elemento di riserva nella regione originale (R1), dopo che diventa disponibile, segui la stessa procedura descritta nella Fase 2. Questo processo è riassunto come segue:

  1. Crea una seconda replica di lettura tra regioni nella regione originale (R1). A questo punto, l'istanza principale ha due repliche di lettura tra regioni, una nella regione R3 e uno nella regione R1.

  2. Promuovi la replica di lettura tra regioni in R1 come istanza principale finale.

  3. Abilita alta disponibilità per l'istanza principale finale.

  4. Crea una replica di lettura tra regioni dell'istanza principale finale in us-west2.

  5. Per evitare una situazione di "spless-brain", elimina tutte le istanze che non sono (la replica di lettura principale originale e la replica di lettura tra regioni R3).

Come già detto, conviene creare un backup iniziale contiene lo stato iniziale definito per il nuovo database primario.

Il deployment finale ora ha un'istanza principale ad alta disponibilità (con il nome instance-6) e un replica di lettura tra regioni (con il nome instance-8).

Confronto tra vantaggi e svantaggi di una RE manuale e di una RE automatica

La tabella seguente illustra i vantaggi e gli svantaggi dell'implementazione di un processo di RE manualmente o automaticamente. L'obiettivo non è determinare approccio corretto o sbagliato, ma per fornire criteri che ti aiutino a determinare l'approccio migliore per le tue esigenze.

Esecuzione manuale Esecuzione automatica
Vantaggi:
  • Hai un controllo stretto su ogni passo.
  • Puoi visualizzare, risolvere e documentare immediatamente qualsiasi problema nel e il processo di sviluppo.
  • Puoi vedere e rivedere ogni passaggio del processo durante un failover.
 Vantaggi:
  • Puoi implementare e testare i processi di failover.
  • Automation offre l'implementazione più rapida e riduce al minimo i ritardi.
  • L'implementazione è indipendente dagli operatori umani, dalle loro conoscenze e la loro disponibilità.
Svantaggi:
  • L'implementazione manuale dei passaggi del processo rallenta il processo.
  • Gli errori di digitazione umana possono introdurre problemi.
  • Il test del processo richiede in genere diversi ruoli e tempi, potrebbero scoraggiare i test regolari.
 Svantaggi:
  • Se si verifica un errore imprevisto, devi eseguire il debug durante il failover in produzione.
  • Se si verificano errori durante la procedura, è necessario che gli script vengano recuperati (ripristino) dal punto in cui il processo si era interrotto.
  • È necessaria una conoscenza sufficiente dello script e della sua implementazione per capire il comportamento dello script, soprattutto in situazioni di errore.

Come best practice, ti consigliamo di iniziare con un'implementazione manuale. Quindi, esegui volontariamente l'implementazione regolarmente (preferibilmente in produzione) per garantire che il processo manuale funzioni e che tutti i membri del team conoscano i loro ruoli e responsabilità. Ti consigliamo di definire la procedura manuale in un dettagliato del processo. Dopo ogni implementazione, devi confermare per perfezionare il documento del processo.

Dopo aver perfezionato il processo e aver verificato che sia affidabile, determinare se automatizzare il processo. Se selezioni e implementi una un processo automatizzato, devi testarlo regolarmente in produzione garantire un'implementazione affidabile.

Esegui la pulizia

Per evitare che al tuo account Google Cloud vengano addebitati costi relativi alla in questo tutorial, puoi eliminare il progetto Google Cloud che hai creato per questo tutorial.

Elimina il progetto

  1. In the Google Cloud console, go to the Manage resources page.

    Go to Manage resources

  2. In the project list, select the project that you want to delete, and then click Delete.
  3. In the dialog, type the project ID, and then click Shut down to delete the project.

Passaggi successivi