Realiza la migración de MySQL

En esta guía, se describe cómo realizar la migración de sistemas de una migración de base de datos en vivo desde una instancia de origen de MySQL a una base de datos de Spanner con Datastream y Dataflow.

Antes de comenzar

Antes de realizar la migración de sistemas, verifica que hayas completado las siguientes tareas como parte de la migración de datos en vivo:

  1. Migración del esquema: Implementa tu esquema en Spanner. Para obtener más información, consulta Cómo migrar un esquema desde MySQL.
  2. Migración de relleno: Completa la migración de datos inicial con el trabajo de Dataflow de migración de relleno. Para obtener más información, consulta Realiza la migración de relleno.
  3. Replicación activa de CDC: Verifica que la replicación continua de captura de datos modificados (CDC) esté activa y en buen estado:
    • La transmisión de Datastream lee de forma activa los eventos de cambio de tu base de datos de origen de MySQL y los escribe en el bucket de Cloud Storage.
    • Las notificaciones del bucket de Cloud Storage publican eventos de creación de objetos en el tema de Pub/Sub.
    • El trabajo de Dataflow de transmisión (Cloud_Datastream_to_Spanner) consume la suscripción de Pub/Sub y escribe cambios en Spanner con un retraso de replicación insignificante o inferior a un segundo. Para obtener más información, consulta Migra tus datos de MySQL.
  4. Validación de datos inicial: Ejecuta verificaciones de validación de datos para verificar la coherencia de los datos entre la instancia de origen de MySQL y el destino de Spanner. Para obtener más información, consulta Valida tu migración de datos.
  5. Limpia el estado de la cola de mensajes no entregados (DLQ): Verifica que el directorio de DLQ de replicación directa grave en Cloud Storage (por ejemplo, gs://MIGRATION_BUCKET/ENV/SERVICE/cdc/DB_SCHEMA/severe/) esté completamente vacío. Si existen errores graves, resuelve los problemas subyacentes y vuelve a reproducir todos los eventos de cambio fallidos con un trabajo por lotes retryDLQ antes de iniciar la migración de sistemas. Para obtener más información, consulta Supervisa y resuelve errores de DLQ de CDC.
  6. Configuración de replicación inversa (preparación para la conmutación por recuperación): Si necesitas una ruta de conmutación por recuperación de contingencia, configura una canalización de replicación inversa activa desde Spanner a tu base de datos de origen de MySQL. Para obtener más información, consulta Configura la conmutación por recuperación a MySQL.

Roles obligatorios

Realiza la migración de sistemas

En las siguientes secciones, se describe cómo vaciar la canalización de escritura y verificar que todos los cambios de origen se repliquen en Spanner antes de cambiar las escrituras de la aplicación.

Verifica el estado de la canalización y el estado de la DLQ

Antes de pausar el tráfico de escritura de la aplicación o iniciar el tiempo de inactividad, verifica que tu canalización de replicación directa no tenga eventos de cambio abandonados en su DLQ:

  1. En la Google Cloud consola de, ve a la página Detalles del trabajo de tu canalización de Dataflow de transmisión.
  2. En la pestaña Métricas personalizadas, inspecciona el contador personalizado Total permanent errors.

  3. Si este contador es mayor que 0, verifica tu directorio de DLQ grave de Cloud Storage (por ejemplo, gs://MIGRATION_BUCKET/ENV/SERVICE/cdc/DB_SCHEMA/severe/) y verifica que el directorio esté vacío.

Pausa las escrituras de la aplicación

  1. Pausa todo el tráfico de escritura de la base de datos en tu aplicación.
  2. Permite que las transacciones activas en las instancias principales de MySQL de origen se confirmen y vacíen por completo.

Realiza un seguimiento de Datastream y paúsalo

  1. En la Google Cloud consola de, ve a la página Detalles de la transmisión de tu transmisión.
  2. En la pestaña Supervisión, inspecciona el gráfico actualidad de los datos (tipo de métrica de Cloud Monitoring: datastream.googleapis.com/stream/freshness). Espera a que el valor de la métrica disminuya a 0. Esto indica que Datastream capturó y procesó todos los cambios de la base de datos de origen hasta el momento en que se pausaron las escrituras. Para obtener más información, consulta Supervisa una transmisión.

  3. Verifica que no pasen eventos de replicación por la transmisión. En la pestaña Supervisión, inspecciona el gráfico Rendimiento (tipo de métrica de Monitoring: datastream.googleapis.com/stream/event_count) y verifica que la tasa de eventos sea 0.

    Como alternativa, para verificar de forma programática con el Explorador de métricas, consulta el recuento de eventos con el lenguaje de consulta de Monitoring (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
     Reemplaza STREAM_ID por el ID de tu transmisión.

    Verifica que esta métrica informe 0 durante al menos dos períodos de agregación consecutivos.

  4. Pausa tu transmisión de Datastream con la Google Cloud consola o la API, y espera a que el estado de la transmisión cambie a PAUSED.

Espera a que se vacíen los datos de cambio en curso

  1. En la Google Cloud consola de, ve a la página Detalles de la transmisión de tu transmisión.
  2. En la pestaña Supervisión, inspecciona el gráfico Latencia del sistema (tipo de métrica de Monitoring: datastream.googleapis.com/stream/system_latencies).
  3. Ten en cuenta el valor de latencia del percentil 99 (P99) y espera al menos dos veces la latencia del sistema P99 más 30 segundos después de pausar la transmisión. Este período de espera ayuda a garantizar que todos los archivos de datos de cambio generados antes de la pausa se escriban de forma segura en Cloud Storage y que sus eventos de creación de objetos se publiquen en Pub/Sub.
  4. Verifica que tu trabajo de Dataflow de transmisión haya consumido todos los eventos de cambio pendientes. En la Google Cloud consola de, ve a la página Suscripciones de Pub/Sub y, luego, selecciona la suscripción creada durante la configuración de la migración de CDC.
  5. En la pestaña Supervisión, inspecciona el gráfico Recuento de mensajes no confirmados (tipo de métrica de Monitoring: pubsub.googleapis.com/subscription/num_undelivered_messages) y verifica que el recuento sea 0.

Verifica que se haya completado la replicación

  1. Verifica que tu canalización de Dataflow de transmisión haya terminado de escribir todos los cambios replicados. En la página Detalles del trabajo de tu trabajo de transmisión, selecciona la pestaña Métricas personalizadas y, luego, inspecciona el contador de usuarios Replication lag total latency_MAX. Espera a que el valor del contador llegue a 0.

    Como alternativa, en el Explorador de métricas, consulta el contador de usuarios con 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
     Reemplaza JOB_ID por el ID de tu trabajo de Dataflow.

  2. Verifica que la actividad de escritura se haya detenido en la base de datos de Spanner de destino. En la página Detalles de la base de datos de tu base de datos de destino, selecciona la pestaña Supervisión y, luego, inspecciona el gráfico Rendimiento de escritura (tipo de métrica de Monitoring: spanner.googleapis.com/transaction_stat/total/bytes_written_count). Verifica que el rendimiento de escritura sea 0 durante al menos dos períodos de agregación consecutivos de 1 minuto.

  3. Realiza una verificación final de la DLQ de replicación directa. Inspecciona los directorios de DLQ graves y de reintento en Cloud Storage (por ejemplo, gs://MIGRATION_BUCKET/ENV/SERVICE/cdc/DB_SCHEMA/severe/ y gs://MIGRATION_BUCKET/ENV/SERVICE/cdc/DB_SCHEMA/retry/) para verificar que permanezcan vacíos.

  4. Vacía tu trabajo de Dataflow de transmisión:

    1. En la Google Cloud consola de, ve a la página Detalles del trabajo de tu trabajo de transmisión.
    2. Haz clic en Detener trabajo, selecciona Vaciar y, luego, haz clic en Detener trabajo.
    3. Espera hasta que el estado del trabajo cambie a Drained. Para obtener más información, consulta Detén una canalización en ejecución.

  5. Realiza la verificación de DLQ posterior al vaciado: Después de que el estado del trabajo cambie a Drained, inspecciona los directorios de DLQ graves y de reintento en Cloud Storage por última vez. Verifica que no aparezcan archivos de error nuevos mientras se vacían los datos en curso. Si existen archivos, resuélvelos y vuelve a reproducirlos. Para obtener más información, consulta Supervisa y resuelve errores de DLQ de CDC.

Realiza la migración de sistemas de la aplicación

Cambia las conexiones de la base de datos de la aplicación a Spanner y reanuda el tráfico de lectura y escritura en vivo:

  1. Actualiza la configuración de la aplicación o las cadenas de conexión de la base de datos para segmentar tu base de datos de Spanner.
  2. Inicia los servicios de la aplicación y verifica que el tráfico de lectura y escritura en vivo se ejecute correctamente en Spanner.
  3. Supervisa tu canalización de replicación inversa en busca de errores. Si una escritura de Spanner no se replica en MySQL, Dataflow guarda el registro fallido en un directorio de DLQ en Cloud Storage (por ejemplo, gs://MIGRATION_BUCKET/ENV/SERVICE/reverse/DB_SCHEMA/severe/). Revisa esta ruta con regularidad para verificar que permanezca vacía. Si aparecen registros fallidos, consulta Supervisa y resuelve errores de replicación inversa.

¿Qué sigue?