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

Fase 1: configura un'istanza di database ad alta affidabilità per il RE

Le seguenti fasi (1-3) ti guidano attraverso 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 quando possibile (ad esempio, la versione predefinita di Cloud SQL). Nell'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 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 della proceduraREa e di failback in questo tutorial. Puoi anche fornire i tuoi nomi e le tue regioni.

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

• In Cloud Shell, imposta le variabili di ambiente in base alle 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 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 delle istanze.

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 si mette in pausa finché l'istanza non viene creata.

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 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 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 dati di test.

Modifica dell'istanza principale in un'istanza di database HA

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

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

  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 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 consoleGoogle Cloud , vai alla pagina Istanze di Cloud SQL.

   Vai a Istanze

   

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

3. Utilizzando la stessa password di root per il database primario, accedi alla replica di lettura cross-region:

   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 cross-region completa, 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 cross-region 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 in base a un file di dump

Un modo per ottimizzare la creazione di una replica di lettura cross-region è sincronizzare la replica da uno stato precedente e coerente del database principale anziché sincronizzare al momento dell'accesso al nuovo database principale. Questa ottimizzazione richiede la creazione di un file di dump che la replica utilizza come stato iniziale.

Per i passaggi per creare una replica basata su un file di dump, vedi 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 replica completa.

Fase 2: simulazione di un disastro (interruzione del servizio a livello di regione)

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

Verifica il ritardo della replica di lettura tra regioni

Nei passaggi successivi, determini il ritardo di replica della replica di lettura cross-region:

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:

   

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

   

Idealmente, il ritardo di replica è pari a zero quando si verifica un'interruzione della regione primaria, in quanto un ritardo pari a zero garantisce la replica di tutte le transazioni. Se non è 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 sul database primario.

Rendere non disponibile l'istanza principale

Nei passaggi successivi, simulerai un disastro arrestando il database primario. Se una replica di lettura tra regioni è collegata all'istanza principale, devi prima scollegarla, altrimenti non puoi arrestare l'istanza Cloud SQL.

1. In Cloud Shell, rimuovi la replica di lettura tra regioni dalla regione primaria:

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

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

2. Arresta l'istanza di database principale:

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

Implementare il DR

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

   

   Dopo aver promosso la replica di lettura tra regioni come nuova istanza principale, attivala per l'alta disponibilità. Come best practice, devi aggiornare le variabili di 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 primaria:

   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, la pagina Istanze di Cloud SQL nella console Google Cloud mostra che la nuova istanza principale (instance-3) è abilitata come HA e ha una replica di lettura cross-region (instance-5):

   

6. (Facoltativo) Se esegui backup regolari, segui la procedura descritta in precedenza per sincronizzare il nuovo primario con l'ultima versione di backup.

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

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

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

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

Elimina il primario originale per evitare una situazione di split-brain

Per evitare una situazione di split-brain, devi eliminare il primario originale (o renderlo 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, il contenuto dei due database non è coerente. Dopo un failover, il database primario originale non è aggiornato e non deve ricevere traffico di lettura o scrittura.

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

  gcloud sql instances delete $former_primary_name
  

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

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

  

Fase 3: implementazione di un fallback

Per implementare un fallback alla regione originale (R1) dopo che è diventata disponibile, segui la stessa procedura descritta nella fase 2. La procedura è riassunta come segue:

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

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

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

4. Crea una replica di lettura tra regioni dell'istanza primaria 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, la best practice consiste nel creare un backup iniziale che contenga lo stato iniziale definito per il nuovo database principale.

Il deployment finale ora ha un database primario HA (con il nome instance-6) e una replica di lettura cross-region (con il nome instance-8).

Confronto tra i vantaggi e gli svantaggi di un RE manuale e automatico

La tabella seguente illustra i vantaggi e gli svantaggi dell'implementazione di una proceduraREP manuale o automatica. L'obiettivo non è determinare un approccio corretto rispetto a uno errato, ma fornire criteri per aiutarti a determinare l'approccio migliore per le tue esigenze.

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

Dopo aver perfezionato la procedura e aver verificato che sia affidabile, decidi se automatizzarla. Se selezioni e implementi un processo automatizzato, devi testarlo regolarmente in produzione per assicurarti di poterlo implementare in modo affidabile.