Esegui il cutover da MySQL

Questa guida descrive come eseguire il cutover di una migrazione live del database da un'istanza di origine MySQL a un database Spanner utilizzando Datastream e Dataflow.

Prima di iniziare

Prima di eseguire il cutover, verifica di aver completato le seguenti attività nell'ambito della migrazione live dei dati:

  1. Migrazione dello schema: esegui il deployment dello schema in Spanner. Per saperne di più, consulta Eseguire la migrazione di uno schema da MySQL.
  2. Migrazione di backfill: completa la migrazione iniziale dei dati utilizzando il job Dataflow di migrazione di backfill. Per saperne di più, consulta Eseguire la migrazione di backfill.
  3. Replica CDC attiva: verifica che la replica continua di Change Data Capture (CDC) sia attiva e integra:
    • Lo stream Datastream legge attivamente gli eventi di modifica dal database MySQL di origine e li scrive nel bucket Cloud Storage.
    • Le notifiche del bucket Cloud Storage pubblicano gli eventi di creazione degli oggetti nell'argomento Pub/Sub.
    • Il job Dataflow di streaming (Cloud_Datastream_to_Spanner) utilizza la sottoscrizione Pub/Sub e scrive le modifiche in Spanner con un ritardo di replica inferiore al secondo o trascurabile. Per saperne di più, consulta Eseguire la migrazione dei dati MySQL.
  4. Convalida iniziale dei dati: esegui i controlli di convalida dei dati per verificare la coerenza dei dati tra l'istanza MySQL di origine e la destinazione Spanner. Per saperne di più, consulta Convalidare la migrazione dei dati.
  5. Stato della coda di messaggi non recapitabili (DLQ): verifica che la directory DLQ di inoltro della replica in Cloud Storage (ad esempio, gs://MIGRATION_BUCKET/ENV/SERVICE/cdc/DB_SCHEMA/severe/) sia completamente vuota. Se esistono errori gravi, risolvi i problemi sottostanti e riproduci tutti gli eventi di modifica non riusciti utilizzando un job batch retryDLQ prima di avviare il cutover. Per saperne di più, consulta Monitorare e risolvere gli errori DLQ di CDC.
  6. Configurazione della replica inversa (preparazione per il fallback): se hai bisogno di un percorso di fallback di emergenza, configura una pipeline di replica inversa attiva da Spanner al database MySQL di origine. Per saperne di più, consulta Configurare il fallback a MySQL.

Ruoli obbligatori

Eseguire il cutover

Le sezioni seguenti descrivono come svuotare la pipeline di scrittura e verificare che tutte le modifiche di origine vengano replicate in Spanner prima di passare alle scritture dell'applicazione.

Verificare l'integrità della pipeline e lo stato della DLQ

Prima di mettere in pausa il traffico di scrittura dell'applicazione o di avviare l'inattività, verifica che la pipeline di replica di inoltro non abbia eventi di modifica bloccati nella DLQ:

  1. Nella Google Cloud console, vai alla pagina dei dettagli Dettagli job della pipeline Dataflow di streaming.
  2. Nella scheda Metriche personalizzate, esamina il contatore personalizzato Total permanent errors.

  3. Se questo contatore è maggiore di 0, controlla la directory DLQ grave di Cloud Storage (ad esempio, gs://MIGRATION_BUCKET/ENV/SERVICE/cdc/DB_SCHEMA/severe/) e verifica che la directory sia vuota.

Mettere in pausa le scritture dell'applicazione

  1. Metti in pausa tutto il traffico di scrittura del database sull'applicazione.
  2. Consenti il commit e lo svuotamento completi delle transazioni attive sulle istanze primarie MySQL di origine.

Monitorare e mettere in pausa Datastream

  1. Nella Google Cloud console, vai alla pagina Dettagli stream dello stream.
  2. Nella scheda Monitoraggio, esamina il grafico Aggiornamento dei dati (tipo di metrica di Cloud Monitoring: datastream.googleapis.com/stream/freshness). Attendi che il valore della metrica diminuisca fino a 0. Ciò indica che Datastream ha acquisito ed elaborato tutte le modifiche del database di origine fino al momento in cui le scritture sono state messe in pausa. Per saperne di più, consulta Monitorare uno stream.

  3. Verifica che non vengano trasmessi eventi di replica tramite lo stream. Nella scheda Monitoraggio, esamina il grafico Velocità effettiva (tipo di metrica di Monitoring: datastream.googleapis.com/stream/event_count) e verifica che la frequenza degli eventi sia 0.

    In alternativa, per eseguire la verifica a livello di programmazione utilizzando Metrics Explorer, esegui una query sul conteggio degli eventi utilizzando Monitoring Query Language (MQL): 

    fetch datastream.googleapis.com/Stream
| metric 'datastream.googleapis.com/stream/event_count'
| filter (resource.stream_id == 'STREAM_ID')
| align rate(1m)
| group_by [], [value_event_count_sum: sum(value.event_count)]
| every 1m
     Sostituisci STREAM_ID con l'ID dello stream.

    Verifica che questa metrica riporti 0 per almeno due periodi di aggregazione consecutivi.

  4. Metti in pausa lo stream Datastream utilizzando la Google Cloud console o l'API e attendi che lo stato dello stream diventi PAUSED.

Attendere lo svuotamento dei dati di modifica in corso

  1. Nella Google Cloud console, vai alla pagina Dettagli stream dello stream.
  2. Nella scheda Monitoraggio, esamina il grafico Latenza di sistema (tipo di metrica di Monitoring: datastream.googleapis.com/stream/system_latencies).
  3. Prendi nota del valore di latenza del 99° percentile (P99) e attendi almeno due volte la latenza di sistema P99 più 30 secondi dopo aver messo in pausa lo stream. Questo periodo di attesa contribuisce a garantire che tutti i file di dati di modifica generati prima della messa in pausa vengano scritti in modo sicuro in Cloud Storage e che gli eventi di creazione degli oggetti vengano pubblicati in Pub/Sub.
  4. Verifica che il job Dataflow di streaming abbia utilizzato tutti gli eventi di modifica in attesa. Nella Google Cloud console, vai alla pagina **Sottoscrizioni** di Pub/Sub e seleziona la sottoscrizione creata durante la configurazione della migrazione CDC.
  5. Nella scheda Monitoraggio, esamina il grafico Conteggio messaggi non riconosciuti (tipo di metrica di Monitoring: pubsub.googleapis.com/subscription/num_undelivered_messages) e verifica che il conteggio sia 0.

Verificare che la replica sia completa

  1. Verifica che la pipeline Dataflow di streaming abbia terminato di scrivere tutte le modifiche replicate. Nella pagina Dettagli job del job di streaming, seleziona la scheda Metriche personalizzate ed esamina il contatore utente Replication lag total latency_MAX. Attendi che il valore del contatore raggiunga 0.

    In alternativa, in Metrics Explorer, esegui una query sul contatore utente utilizzando MQL: 

    fetch dataflow_job
| metric 'dataflow.googleapis.com/job/user_counter'
| filter (metric.job_id == 'JOB_ID' && metric.metric_name == 'Replication lag total latency_MAX')
| group_by 1m, [value_p99_latency: percentile(value.user_counter, 99)]
| every 1m
     Sostituisci JOB_ID con l'ID del job Dataflow.

  2. Verifica che l'attività di scrittura sia stata interrotta nel database Spanner di destinazione. Nella pagina Dettagli database del database di destinazione, seleziona la scheda Monitoraggio ed esamina il grafico Velocità effettiva di scrittura (tipo di metrica di Monitoring: spanner.googleapis.com/transaction_stat/total/bytes_written_count). Verifica che la velocità effettiva di scrittura sia 0 per almeno due periodi di aggregazione consecutivi di 1 minuto.

  3. Esegui un controllo finale della DLQ di replica di inoltro. Esamina le directory DLQ gravi e di ripetizione in Cloud Storage (ad esempio, gs://MIGRATION_BUCKET/ENV/SERVICE/cdc/DB_SCHEMA/severe/ e gs://MIGRATION_BUCKET/ENV/SERVICE/cdc/DB_SCHEMA/retry/) per verificare che rimangano vuote.

  4. Svuota il job Dataflow di streaming:

    1. Nella Google Cloud console, vai alla pagina Dettagli job del tuo job di streaming.
    2. Fai clic su Arresta job, seleziona Svuota e poi fai clic su Arresta job.
    3. Attendi che lo stato del job diventi Drained. Per saperne di più, consulta Arrestare una pipeline in esecuzione.

  5. Esegui la verifica della DLQ dopo lo svuotamento: dopo che lo stato del job è diventato Drained, esamina le directory DLQ gravi e di ripetizione in Cloud Storage un'ultima volta. Verifica che non siano stati visualizzati nuovi file di errore durante lo svuotamento dei dati in corso. Se esistono file, risolvili e riproducili. Per saperne di più, consulta Monitorare e risolvere gli errori DLQ di CDC.

Eseguire il cutover dell'applicazione

Passa le connessioni del database dell'applicazione a Spanner e riprendi il traffico di lettura e scrittura live:

  1. Aggiorna la configurazione dell'applicazione o le stringhe di connessione al database in modo che puntino al database Spanner.
  2. Avvia i servizi dell'applicazione e verifica che il traffico di lettura e scrittura live venga eseguito correttamente su Spanner.
  3. Monitora la pipeline di replica inversa per verificare la presenza di errori. Se una scrittura Spanner non viene replicata di nuovo in MySQL, Dataflow salva il record non riuscito in una directory DLQ in Cloud Storage (ad esempio, gs://MIGRATION_BUCKET/ENV/SERVICE/reverse/DB_SCHEMA/severe/). Controlla regolarmente questo percorso per verificare che rimanga vuoto. Se vengono visualizzati record non riusciti, consulta Monitorare e risolvere gli errori di replica inversa.

Passaggi successivi