Esegui il fallback a MySQL

Questa guida descrive come eseguire il fallback e il rollback del disaster recovery da Spanner alle istanze MySQL di origine.

Se dopo il cutover a Spanner riscontri un degrado imprevisto delle prestazioni, errori dell'applicazione non recuperabili o blocchi funzionali critici, utilizza le procedure nelle sezioni seguenti per eseguire il rollback alle istanze primarie MySQL:

Prima di iniziare

Prima di avviare le procedure di fallback, verifica i seguenti prerequisiti:

  1. Replica inversa attiva: verifica che la pipeline Dataflow di replica inversa (Spanner_to_SourceDb) sia in esecuzione e utilizzi attivamente gli stream di modifiche in tempo reale di Spanner in modalità di filtro forward_migration. Per ulteriori informazioni, consulta Configurare il fallback a MySQL.
  2. Disponibilità di MySQL di origine: verifica che il database MySQL di origine sia online, raggiungibile da Dataflow e in grado di accettare connessioni di scrittura.
  3. Periodo di manutenzione: avvisa le parti interessate che è necessario un periodo di inattività pianificato mentre le scritture di Spanner sono in pausa e la replica inversa viene svuotata.

Ruoli obbligatori

Mettere in pausa le scritture di Spanner

  1. Metti in pausa tutto il traffico di scrittura del database su Spanner nella tua applicazione.
  2. Consenti alle transazioni attive su Spanner di eseguire il commit e lo svuotamento completi.

Consentire lo svuotamento della replica inversa

Le sezioni seguenti descrivono come verificare che tutte le modifiche scritte in Spanner dopo il cutover vengano replicate di nuovo in MySQL prima di passare alle scritture dell'applicazione.

Monitorare il ritardo della replica

Monitora il ritardo della replica per verificare che tutte le modifiche in corso vengano scritte in MySQL:

  1. Nella Google Cloud console, vai alla pagina Dettagli job del job Dataflow di replica inversa.
  2. Nella scheda Metriche personalizzate, esamina il contatore utente replication_lag_in_seconds_LOGICAL_SHARD_NAME_MAX. Per ulteriori informazioni, consulta Configurare il fallback a MySQL.
  3. Attendi che il valore del contatore raggiunga 0.

In alternativa, in Metrics Explorer, esegui una query sul contatore utente utilizzando Monitoring Query Language (MQL): 

fetch dataflow_job
| metric 'dataflow.googleapis.com/job/user_counter'
| filter (metric.job_id == 'JOB_ID' && metric.metric_name == 'replication_lag_insecondsLOGICAL_SHARD_NAME_MAX')
| group_by 1m, [value_p99_latency: percentile(value.user_counter, 99)]
| every 1m
Sostituisci quanto segue: * JOB_ID: l'ID del job Dataflow di replica inversa. * LOGICAL_SHARD_NAME: il nome dello shard logico configurato per il database di origine.

Verificare l'attività di scrittura di MySQL

Verifica che le operazioni di scrittura della replica inversa siano state completate nel database di origine:

  1. Nel database primario MySQL di origine, esamina le query attive e le metriche di connessione al database.
  2. Verifica che il traffico di scrittura dalla pipeline di replica inversa sia stato interrotto.

Verificare lo stato DLQ pulito

Esamina le code di messaggi non recapitabili (DLQ) per verificare che non si siano verificati errori non gestiti durante la replica inversa:

  1. Nella Google Cloud console, vai alla pagina Dettagli job del job Dataflow di replica inversa. Nella scheda Metriche personalizzate , esamina il contatore utente severe_error_count.

  2. Esamina le directory DLQ di replica inversa gravi e di ripetizione in Cloud Storage (ad esempio, gs://MIGRATION_BUCKET/ENV/SERVICE/reverse/DB_SCHEMA/severe/ e gs://MIGRATION_BUCKET/ENV/SERVICE/reverse/DB_SCHEMA/retry/).

    Puoi elencare i contenuti della directory DLQ grave utilizzando gcloud CLI:

    gcloud storage ls gs://MIGRATION_BUCKET/ENV/SERVICE/reverse/DB_SCHEMA/severe/

    Sostituisci quanto segue:

    • MIGRATION_BUCKET: il nome del bucket Cloud Storage.
    • ENV: il nome dell'ambiente di deployment (ad esempio, prod).
    • SERVICE: il nome dell'applicazione o del servizio.
    • DB_SCHEMA: il nome dello schema del database.

  3. Verifica che le directory DLQ rimangano completamente vuote.

  4. Se esistono file di errore, risolvi i problemi sottostanti e riproduci i record non riusciti prima di procedere. Per ulteriori informazioni, consulta Monitorare e risolvere gli errori di replica inversa.

Riprendere lo streaming CDC in avanti

Se prevedi di riprendere la migrazione in avanti a Spanner in futuro, riprendi lo stream Datastream in avanti:

  1. Nella Google Cloud console, vai alla pagina Dettagli stream dello stream.
  2. Fai clic su Riprendi e attendi che lo stato dello stream cambi in RUNNING. Per ulteriori informazioni, consulta Eseguire la migrazione dei dati MySQL.

In alternativa, per riprendere lo stream utilizzando gcloud CLI, esegui il comando gcloud datastream streams resume:

gcloud datastream streams resume STREAM_ID \
    --location=LOCATION

Sostituisci quanto segue:

  • STREAM_ID: l'ID dello stream Datastream.
  • LOCATION: la Google Cloud regione in cui si trova lo stream.

Reindirizzare le scritture a MySQL

  1. Aggiorna la configurazione dell'applicazione e le stringhe di connessione al database in modo che puntino alle istanze del database primario MySQL di origine.
  2. Avvia i servizi dell'applicazione e riprendi il traffico di lettura e scrittura in tempo reale su MySQL.
  3. Verifica che le operazioni di lettura e scrittura dell'applicazione vengano eseguite correttamente sul database MySQL.

Passaggi successivi