Realiza un resguardo a MySQL

En esta guía, se describe cómo realizar una recuperación ante desastres y una reversión de Spanner a tus instancias de MySQL de origen.

Si experimentas una degradación inesperada del rendimiento, errores de aplicación irrecuperables o bloqueadores funcionales críticos después de realizar el cambio a Spanner, usa los procedimientos de las siguientes secciones para revertir a tus instancias principales de MySQL:

Antes de comenzar

Antes de iniciar los procedimientos de resguardo, verifica los siguientes requisitos previos:

  1. Replicación inversa activa: Verifica que la canalización de Dataflow de replicación inversa (Spanner_to_SourceDb) se esté ejecutando y consumiendo de forma activa las flujos de cambios de Spanner en el modo de filtrado forward_migration. Para obtener más información, consulta Configura el resguardo a MySQL.
  2. Disponibilidad de MySQL de origen: Verifica que tu base de datos de MySQL de origen esté en línea, que se pueda acceder a ella desde Dataflow y que pueda aceptar conexiones de escritura.
  3. Período de mantenimiento: Alerta a las partes interesadas que se requiere un período de inactividad planificado mientras se pausan las escrituras de Spanner y se agota la replicación inversa.

Roles obligatorios

Pausa las escrituras de Spanner

  1. Pausa todo el tráfico de escritura de la base de datos a Spanner en tu aplicación.
  2. Permite que las transacciones activas en Spanner se confirmen y se agoten por completo.

Permite que se agote la replicación inversa

En las siguientes secciones, se describe cómo verificar que todos los cambios escritos en Spanner después del cambio se repliquen en MySQL antes de cambiar las escrituras de la aplicación.

Supervisa el retraso de replicación

Haz un seguimiento del retraso de replicación para verificar que todos los cambios en curso se escriban en MySQL:

  1. En la Google Cloud consola de, ve a la página Detalles del trabajo de tu trabajo de Dataflow de replicación inversa.
  2. En la pestaña Métricas personalizadas, inspecciona el contador de usuarios replication_lag_in_seconds_LOGICAL_SHARD_NAME_MAX. Para obtener más información, consulta Configura el resguardo a MySQL.
  3. Espera a que el valor del contador llegue a 0.

Como alternativa, en el Explorador de métricas, consulta el contador de usuarios con el lenguaje de consulta de Monitoring (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
Reemplaza lo siguiente: * JOB_ID: el ID de tu trabajo de Dataflow de replicación inversa. * LOGICAL_SHARD_NAME: el nombre de fragmento lógico configurado para tu base de datos de origen.

Verifica la actividad de escritura de MySQL

Verifica que las operaciones de escritura de replicación inversa se hayan completado en tu base de datos de origen:

  1. En tu base de datos principal de MySQL de origen, inspecciona las consultas activas y las métricas de conexión de la base de datos.
  2. Verifica que se haya detenido el tráfico de escritura de la canalización de replicación inversa.

Verifica el estado limpio de la DLQ

Inspecciona las colas de mensajes no entregados (DLQ) para verificar que no se hayan producido errores no controlados durante la replicación inversa:

  1. En la Google Cloud consola de, ve a la página Detalles del trabajo de tu trabajo de Dataflow de replicación inversa. En la pestaña Métricas personalizadas , inspecciona el contador de usuarios severe_error_count.

  2. Inspecciona los directorios de DLQ de replicación inversa graves y de reintento en Cloud Storage (por ejemplo, gs://MIGRATION_BUCKET/ENV/SERVICE/reverse/DB_SCHEMA/severe/ y gs://MIGRATION_BUCKET/ENV/SERVICE/reverse/DB_SCHEMA/retry/).

    Puedes enumerar el contenido del directorio de DLQ grave con la gcloud CLI:

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

    Reemplaza lo siguiente:

    • MIGRATION_BUCKET: el nombre de tu bucket de Cloud Storage.
    • ENV: el nombre de tu entorno de implementación (por ejemplo, prod).
    • SERVICE: el nombre de tu aplicación o servicio.
    • DB_SCHEMA: el nombre del esquema de tu base de datos.

  3. Verifica que los directorios de DLQ permanezcan completamente vacíos.

  4. Si existen archivos de error, resuelve los problemas subyacentes y vuelve a reproducir los registros fallidos antes de continuar. Para obtener más información, consulta Supervisa y resuelve errores de replicación inversa.

Reanuda la transmisión de CDC directa

Si planeas reanudar la migración directa a Spanner en el futuro, reanuda la transmisión directa de Datastream:

  1. En la Google Cloud consola de, ve a la página Detalles de la transmisión de tu transmisión.
  2. Haz clic en Reanudar y espera a que el estado de la transmisión cambie a RUNNING. Para obtener más información, consulta Migra tus datos de MySQL.

Como alternativa, para reanudar la transmisión con la gcloud CLI, ejecuta el comando gcloud datastream streams resume:

gcloud datastream streams resume STREAM_ID \
    --location=LOCATION

Reemplaza lo siguiente:

  • STREAM_ID: el ID de tu transmisión de Datastream.
  • LOCATION: la Google Cloud región en la que se encuentra tu transmisión.

Redirige las escrituras a MySQL

  1. Actualiza la configuración de la aplicación y las cadenas de conexión de la base de datos para orientar tus instancias principales de la base de datos de MySQL de origen.
  2. Inicia los servicios de la aplicación y reanuda el tráfico de lectura y escritura en vivo en MySQL.
  3. Verifica que las operaciones de lectura y escritura de la aplicación se ejecuten correctamente en la base de datos de MySQL.

¿Qué sigue?