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

---

Nota: questo documento o questa sezione include riferimenti a uno o più termini che Google considera irrispettosi o offensivi. I termini vengono utilizzati perché sono parole chiave nel software descritto nel documento.

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

In questo tutorial configurerai un'istanza Cloud SQL per MySQL ad alta disponibilità per il ripristino di emergenza e simulerai un'interruzione. Quindi, seguirai il processo di RE per recuperare il deployment iniziale dopo la risoluzione dell'interruzione.

Importante: questo tutorial si applica solo al ripristino di emergenza generale (RE), disponibile per tutte le istanze Cloud SQL per MySQL. Se usi la versione Cloud SQL Enterprise Plus, hai la possibilità di utilizzare il ripristino di emergenza avanzato (RE). Per maggiori informazioni sul RE avanzato, consulta gli articoli Ripristino di emergenza avanzato e Utilizzo del ripristino di emergenza avanzato. Il RE avanzato è in anteprima.

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

Per una panoramica del funzionamento del ripristino di emergenza di 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'emergenza e un failover con Cloud SQL per MySQL.
• Scopri la procedura per recuperare il deployment iniziale utilizzando un video di riserva con Cloud SQL per MySQL.

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

Costi

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

• Cloud SQL

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.

   Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

   Go to project selector

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

3. Nella console Google Cloud, attiva Cloud Shell.

   Attiva Cloud Shell

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

Le fasi seguenti (1-3) ti guidano attraverso un processo completo di failover e fallback. Puoi eseguire tutti i comandi utilizzando il comando gcloud in Cloud Shell. Per semplificare la procedura, il tutorial utilizza le impostazioni predefinite, ove possibile (ad esempio, la versione predefinita di Cloud SQL). Nel tuo ambiente di produzione, potresti aggiungere altre configurazioni.

Imposta le variabili di ambiente

Questa sezione fornisce esempi di variabili di ambiente che definiscono i vari nomi e le regioni necessarie 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 di riserva 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	In attesa	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	In attesa	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	In attesa	us-west1
instance-8	Replica di lettura tra regioni	us-west2

Nota: i nomi istanza istanza-2, istanza-4 e istanza-7 non vengono utilizzati per creare istanze Cloud SQL. Queste istanze verranno create automaticamente quando abiliti l'alta disponibilità nelle istanze 1, 3 e 6. Il motivo per fornire nomi aggiuntivi è poter fare riferimento alle istanze ad alta disponibilità create automaticamente e avere uno schema di denominazione coerente che corrisponda alle effettive istanze Cloud SQL create.

I nomi delle istanze nelle tabelle precedenti non sono codificati con i rispettivi ruoli. In una situazione di RE, la funzione di un'istanza potrebbe cambiare, ad esempio, una replica potrebbe diventare la principale. Se il nome della nuova principale contiene la parola replica, potrebbero sorgere confusione e conflitti. Pertanto, consigliamo di non codificare 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 esegue un failover ad alta disponibilità, include i nomi delle istanze in standby per migliorarne la completezza.

La fase di fallback ricrea il deployment originale della fase iniziale nelle stesse regioni originali. Tuttavia, in un elemento 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 fallback, devi utilizzare nomi delle istanze che non corrispondono a quelli utilizzati nella fase iniziale.

• In Cloud Shell, imposta le variabili di ambiente basate sulle 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 i livelli disponibili, quindi assegna un valore diverso al livello principale:

  gcloud sql tiers list
  

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

crea un'istanza di database primaria

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 di MySQL e inserisci la password root al prompt:

   gcloud sql connect $primary_name --user=root
   

2. Al prompt di 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 di MySQL:

   exit;
   

A questo punto, hai un unico database che include una tabella e alcuni dati di test.

Modifica 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 sistema interregionale. La configurazione di una replica di lettura tra regioni è diversa dalla configurazione di Cloud SQL come sistema tra regioni. Per saperne di più, consulta Abilitazione e disabilitazione 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 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 console Google Cloud indica che l'istanza principale (instance-1) è abilitata per l'alta disponibilità ed esiste una replica di lettura tra regioni (instance-3).

3. Utilizza la stessa password root per l'istanza principale, accedi alla replica di lettura tra regioni:

   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 di MySQL:

   exit;
   

Per maggiori dettagli 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, 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 proseguire con la 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 consiste nel sincronizzare la replica da uno stato precedente e coerente del database primario, anziché eseguire la sincronizzazione nel momento in cui si accede a quello nuovo. Questa ottimizzazione richiede la creazione di un file di dump che la replica utilizza come stato iniziale.

Per la procedura di creazione di una replica basata su un file di dump, consulta 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 ignora questo passaggio perché il set di dati di test è sufficientemente piccolo per una replica completa.

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

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

Controlla il ritardo di replica di lettura tra regioni

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

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

   Vai a Istanze

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

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

   

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

   

Idealmente, il ritardo di replica è pari a zero quando si verifica un'interruzione della regione principale, poiché un ritardo pari a zero assicura che tutte le transazioni vengano replicate. Se è diverso da zero, alcune transazioni potrebbero non essere replicate. In questo caso, la replica di lettura tra regioni non conterrà tutte le transazioni di cui è stato eseguito il commit nell'istanza principale.

Rendi non disponibile l'istanza principale

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

1. In Cloud Shell, rimuovi la replica di lettura tra regioni dall'account 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
   

Implementare 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 ti viene richiesto, accetta l'opzione per continuare. La pagina Istanze di Cloud SQL mostra la replica di lettura tra regioni precedente (instance-3) come nuova replica principale e la precedente replica principale (instance-1) interrotta:

   

   Dopo aver promosso la replica di lettura tra regioni come nuova principale, la abiliti 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 la nuova verifica principale:

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

4. Abilita 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, nella pagina Istanze di Cloud SQL nella console Google Cloud viene indicato che la nuova risorsa principale (instance-3) è abilitata ad alta disponibilità e ha una replica di lettura tra regioni (instance-5):

   

6. (Facoltativo) Se hai backup regolari, segui la procedura descritta in precedenza per sincronizzare la nuova versione principale con quella più recente.

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

Gestire un'interruzione di tempo per una regione di breve durata

È possibile che l'interruzione che attiva un failover venga risolta prima del completamento dell'operazione. 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 del processo di failover, la replica di lettura tra regioni potrebbe essere già stata promossa. In questo caso, devi eliminarlo e ricreare una replica di lettura tra regioni.

Elimina i contenuti principali originali per evitare una situazione di suddivisione

Per evitare una situazione di split-brain, devi eliminare l'origine 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 primario originale e nel nuovo database primario. In questo caso, i contenuti dei due database non sono coerenti. Dopo un failover, il database primario originale è obsoleto e non deve ricevere traffico di lettura o scrittura.

• In Cloud Shell, elimina il file principale originale:

  gcloud sql instances delete $former_primary_name
  

  Quando ti viene 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) come parte del deployment:

  

Fase 3: implementazione di un fallback

Per implementare un elemento di riserva per la regione originale (R1) quando 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, la principale ha due repliche di lettura tra regioni, una nell'area geografica R3 e una nella regione R1.

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

3. Attiva alta disponibilità per l'istanza primaria finale.

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

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

Come discusso in precedenza, la best practice prevede di creare un backup iniziale che contenga lo stato di avvio definito per il nuovo database principale.

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

Confronto di vantaggi e svantaggi di un ripristino di emergenza manuale rispetto a un ripristino automatico

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

Esecuzione manuale	Esecuzione automatica
Vantaggi: Hai il pieno controllo di ogni passaggio. Puoi visualizzare, risolvere e documentare immediatamente qualsiasi problema durante la procedura. Puoi visualizzare ed esaminare ogni passaggio del processo 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 disponibilità.
Svantaggi: L'implementazione manuale dei passaggi rallenta il processo. Gli errori di digitazione da parte di persone fisiche possono introdurre problemi. Il test del processo in genere prevede diversi ruoli e tempi, il che potrebbe scoraggiare l'esecuzione di 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, gli script devono riprendere (recuperare) dal punto in cui il processo è stato interrotto. Per comprendere il comportamento dello script, soprattutto in situazioni di errore, è necessaria una conoscenza sufficiente dello script e della sua implementazione.

Come best practice, ti consigliamo di iniziare con un'implementazione manuale. Quindi, esegui volontariamente l'implementazione con regolarità (preferibilmente in produzione) per assicurarti 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 documento relativo alla procedura passo passo. Dopo ogni implementazione, devi confermare o perfezionare il documento della procedura.

Dopo aver perfezionato il processo e aver verificato che sia affidabile, puoi decidere se automatizzarlo. Se selezioni e implementi un processo automatizzato, devi testarlo regolarmente in produzione per assicurarti di poterlo 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

Attenzione: l'eliminazione di un progetto ha i seguenti effetti:

• L'intero contenuto del progetto viene eliminato. Se hai utilizzato un progetto esistente per le attività in questo documento, quando lo elimini elimini anche qualsiasi altro lavoro svolto nel progetto.
• Gli ID progetto personalizzati non sono più disponibili. Quando hai creato questo progetto, potresti aver creato un ID progetto personalizzato che vuoi utilizzare in futuro. Per conservare gli URL che utilizzano l'ID progetto, ad esempio un URL appspot.com, elimina le risorse selezionate all'interno del progetto anziché eliminare l'intero progetto.

Se intendi esplorare più architetture, tutorial o guide rapide, puoi riutilizzare i progetti ed evitare così di superare i limiti di quota.

1. Nella console Google Cloud, vai alla pagina Gestisci risorse.

   Vai a Gestisci risorse

2. Nell'elenco dei progetti, seleziona il progetto che vuoi eliminare, quindi fai clic su Elimina.
3. Nella finestra di dialogo, digita l'ID del progetto e fai clic su Chiudi per eliminare il progetto.

Passaggi successivi

• Ulteriori informazioni sul ripristino di emergenza di Cloud SQL.
• Scopri di più sul ripristino di emergenza per MySQL su Compute Engine.
• Scopri di più sulle architetture di ripristino di emergenza per interruzioni dell'infrastruttura cloud.
• Esplora le architetture di riferimento, i diagrammi e le best practice su Google Cloud. Visita il nostro Cloud Architecture Center.