Ripristino di emergenza Cloud SQL per MySQL: una procedura completa di failover e fallback

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

In questo tutorial, configuri un'istanza Cloud SQL per MySQL ad alta disponibilità (HA) per il ripristino RE e simuli un'interruzione del servizio. Poi, segui la procedura di RE per recuperare il deployment iniziale dopo la risoluzione dell'interruzione.

Questo tutorial è rivolto ad architetti, amministratori e progettisti di database.

Per una panoramica del funzionamento del ripristino di emergenza SQL, consulta 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 disastro e un failover con Cloud SQL per MySQL.
  • Scopri i passaggi per recuperare il deployment iniziale utilizzando un piano di riserva con Cloud SQL per MySQL.

Questo documento si concentra solo sui processi di failover e fallback di RE tra regioni. Per informazioni sulla procedura di failover HA in una singola regione, consulta Panoramica della configurazione per l'alta disponibilità.

Costi

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

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

Al termine delle attività descritte in questo documento, puoi evitare la fatturazione continua eliminando le risorse che hai creato. Per ulteriori informazioni, consulta la sezione 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. Make sure that billing is enabled for your Google Cloud project.

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

    Activate Cloud Shell

Fase 1: configurazione di un'istanza di database HA per il RE

Le seguenti fasi (1-3) illustrano una procedura completa di failover e fallback. Esegui tutti i comandi utilizzando il comando gcloud in Cloud Shell. Per semplificare la procedura, il tutorial utilizza le impostazioni predefinite, se possibile (ad esempio la versione Cloud SQL predefinita). Nell'ambiente di produzione, puoi aggiungere altre configurazioni.

Imposta le variabili di ambiente

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

Le tabelle seguenti descrivono i nomi delle istanze, i relativi ruoli e le regioni di deployment per ogni fase del processo di RE e fallback in questo tutorial. Puoi anche fornire 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 una situazione di RE, la funzione di un'istanza potrebbe cambiare, ad esempio una replica potrebbe diventare principale. Se il nome del nuovo dominio principale contiene la parola replica, potrebbero verificarsi confusione e conflitti. Pertanto, ti consigliamo di non codificare i nomi delle istanze con la funzione o il ruolo che svolgono.

Le tabelle precedenti elencano i nomi delle istanze di standby. Anche se questo tutorial non esegue un failover HA, include i nomi delle istanze di standby per completezza.

La fase di riserva ricrea il deployment originale della fase iniziale nelle stesse regioni originali. Tuttavia, in un piano di riserva, i nomi delle istanze devono cambiare perché i nomi originali non sono immediatamente disponibili anche dopo l'eliminazione dell'istanza originale. Per supportare la creazione rapida delle istanze nella fase di riserva, devi utilizzare nomi di istanze che non corrispondono a quelli utilizzati nella fase iniziale.

  • In Cloud Shell, imposta le variabili di ambiente in base alle specifiche riportate 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 i livelli a tua disposizione e poi assegna un valore diverso a primary_tier:

    gcloud sql tiers list

    Per un elenco delle 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 principale

  1. In Cloud Shell, accedi alla shell MySQL e inserisci la password di root al prompt:

    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 i dati siano stati committati 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 dati di test.

Modificare l'istanza principale in un'istanza di database HA

Puoi configurare Cloud SQL solo come sistema ad alta disponibilità regionale, non come sistema tra regioni. La configurazione di una replica di lettura tra regioni è diversa dalla configurazione di Cloud SQL come sistema tra regioni. Per ulteriori informazioni, consulta Abilitazione e disabilitazione della disponibilità elevata su un'istanza.

  • In Cloud Shell, crea un'istanza Cloud SQL abilitata all'HA:

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

Aggiungere una replica di lettura tra regioni per il RE con aggiornamento automatico

I seguenti passaggi sono sufficienti per creare una replica di lettura tra regioni per 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 console Google Cloud vai alla pagina Istanze di Cloud SQL.

    Vai a Istanze

    La pagina Istanze mostra l'istanza principale e la replica di lettura abilitata all'HA.

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

  3. Utilizzando la stessa password di root per il principale, accedi alla replica di lettura tra regioni:

    gcloud sql connect $cross_region_replica_name --user=root

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

    USE guestbook;

SELECT * FROM entries;

  5. Esci dalla shell MySQL:

    exit;

Per informazioni dettagliate su come configurare una replica di lettura completa tra regioni, consulta la documentazione di Cloud SQL.

Per i database di grandi dimensioni in un ambiente di produzione, ti consigliamo di eseguire il backup del database principale e di creare 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 la Fase 2.

Aggiungere 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 è sincronizzare la replica da uno stato precedente e coerente del database principale anziché al momento dell'accesso alla nuova istanza principale. Questa ottimizzazione richiede la creazione di un file dump utilizzato dalla replica come stato iniziale.

Per la procedura per creare una replica in base a un file dump, consulta Eseguire la replica da un server esterno a Cloud SQL (v1.1). Questo approccio può essere utile per i database di produzione di grandi dimensioni. Tuttavia, questo tutorial salta questo passaggio perché il set di dati di test è abbastanza piccolo per una completa riproduzione.

Fase 2: simulazione di un disastro (interruzione del servizio in una regione)

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

Verificare il ritardo della replica di lettura tra regioni

Nei passaggi che seguono, determina il ritardo di replica della replica di lettura tra regioni:

  1. Nella console Google Cloud, vai alla pagina Istanze Cloud SQL.

    Vai a Istanze

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

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

    L'elenco a discesa delle metriche mostra diverse opzioni, tra cui Ritardo replica.

    La metrica diventa Ritardo di replica. Il grafico non mostra alcun ritardo:

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

Idealmente, il ritardo di replica è zero quando si verifica un'interruzione nella regione principale, poiché un ritardo pari a zero garantisce la replica di tutte le transazioni. Se non è pari a zero, alcune transazioni potrebbero non essere replicate. In questo caso, la replica di lettura tra regioni non conterrà tutte le transazioni committate sulla principale.

Impostare l'istanza principale come non disponibile

Nei passaggi seguenti, simulerai un disastro interrompendo il principale. Se una replica di lettura tra regioni è collegata all'istanza principale, devi prima scollegare la replica, altrimenti non puoi arrestare l'istanza Cloud SQL.

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

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

    Quando richiesto, accetta l'opzione per continuare.

  2. Arresta l'istanza di database principale:

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

Implementare la RE

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

    gcloud sql instances promote-replica $cross_region_replica_name

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

    Le pagine Istanze mostrano lo stato di due istanze, quella principale originale e quella nuova principale.

    Dopo aver promosso la replica di lettura tra regioni come nuova principale, attivala per l'alta disponibilità. Come best practice, devi aggiornare le variabili di ambiente con una denominazione appropriata.

  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 il nuovo account principale:

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

  4. Attiva la nuova istanza principale come istanza regionale 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 la variabile di ambiente cross_region_replica_region su us-west3.

    Al termine del failover, la pagina Istanze Cloud SQL nella console Google Cloud mostra che la nuova istanza principale (instance-3) è abilitata come HA e ha una replica di lettura tra regioni (instance-5):

    La pagina Istanze mostra la nuova istanza principale abilitata per l'HA e una nuova replica di lettura.

  6. (Facoltativo) Se esegui regolarmente i backup, segui la procedura descritta in precedenza per sincronizzare il nuovo account principale con la versione di backup più recente.

  7. (Facoltativo) Se utilizzi un proxy Cloud SQL, configuralo in modo da utilizzare il nuovo principale per riprendere l'elaborazione dell'applicazione.

Gestire un'interruzione di servizio di breve durata in una regione

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

A seconda dello stato specifico della procedura di failover, la replica di lettura tra regioni potrebbe essere già stata promossa. In questo caso, devi eliminarla e ricreare una replica di lettura tra regioni.

Elimina l'account principale originale per evitare una situazione di split-brain

Per evitare una situazione di split-brain, devi eliminare la chiave principale originale (o renderla inaccessibile ai client di database).

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

  • In Cloud Shell, elimina il principale originale:

    gcloud sql instances delete $former_primary_name

    Quando richiesto, accetta l'opzione per continuare.

    Nella console Google Cloud, la pagina Istanze di Cloud SQL non mostra più l'istanza principale originale (instance-1) nell'ambito del deployment:

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

Fase 3: implementazione di un piano di riserva

Per implementare un fallback alla regione originale (R1) quando diventa disponibile, segui la stessa procedura descritta nella Fase 2. Questa procedura è riassunta 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 una nella regione R1.

  2. Promuovi la replica di lettura tra regioni nella regione R1 come principale finale.

  3. Attiva l'alta disponibilità per il principale finale.

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

  5. Per evitare una situazione di split-brain, elimina tutte le istanze non più necessarie (l'istanza principale originale e la replica di lettura tra regioni in R3).

Come discusso in precedenza, è buona prassi creare un backup iniziale che contenga lo stato iniziale definito per il nuovo database principale.

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

Confronto dei vantaggi e degli svantaggi del RE manuale rispetto a quello automatico

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

Esecuzione manuale Esecuzione automatica
Vantaggi:
  • Hai un controllo rigoroso su ogni passaggio.
  • Puoi vedere, risolvere e documentare immediatamente qualsiasi problema nel procedura.
  • Puoi visualizzare ed esaminare ogni passaggio della procedura durante un failover.
 Vantaggi:
  • Puoi implementare e testare i processi di failover.
  • L'Automation offre l'implementazione più rapida e riduce al minimo i ritardi.
  • L'implementazione è indipendente dagli operatori umani, dalle loro conoscenze e dalla loro disponibilità.
Svantaggi:
  • L'implementazione manuale dei passaggi del processo rallenta il processo.
  • Gli errori di battitura possono causare problemi.
  • Il test della procedura in genere richiede diversi ruoli e tempo, il che potrebbe scoraggiare i test regolari.
 Svantaggi:
  • Se si verifica un errore imprevisto, devi eseguire il debug durante il failover di produzione.
  • Se si verificano errori durante la procedura, sono necessari script per riprendere da dove si è interrotto il processo.
  • È necessaria una conoscenza sufficiente dello script e della sua implementazione per comprendere il comportamento dello script, in particolare in caso di errori.

Come best practice, ti consigliamo di iniziare con un'implementazione manuale. Quindi, esegui regolarmente l'implementazione (preferibilmente in produzione) per verificare che la procedura manuale funzioni e che tutti i membri del team conoscano i propri ruoli e le proprie responsabilità. Ti consigliamo di definire la procedura manuale in un documento con la procedura dettagliata. Dopo ogni implementazione, devi confermare o perfezionare il documento relativo alla procedura.

Dopo aver perfezionato il processo e averne verificato l'affidabilità, puoi decidere se automatizzarlo. Se selezioni e implementi un procedura automatizzata, devi testarla regolarmente in produzione per assicurarti di poterla implementare in modo affidabile.

Esegui la pulizia

Per evitare che al tuo account Google Cloud vengano addebitati costi relativi alle risorse utilizzate 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