Configura el resguardo para MySQL

En esta página, se explica cómo configurar la conmutación por recuperación para MySQL con la replicación inversa. La reversión hace referencia a un plan de contingencia para volver a tu base de datos de MySQL de origen si tienes problemas con Spanner.

La replicación inversa es útil cuando surgen problemas inesperados y necesitas revertir a la base de datos de MySQL original con la mínima interrupción del servicio. La replicación inversa te permite revertir la replicación de los datos escritos en Spanner a tu base de datos de MySQL de origen. Esto garantiza que ambas bases de datos sean coherentes con el tiempo.

El flujo de replicación inversa implica los siguientes pasos, que realiza la plantilla de Dataflow Spanner_to_SourceDb:

  1. Leer los cambios de Spanner con los flujos de cambios de Spanner

  2. Asegúrate de que el modo de filtrado sea forward_migration.

  3. Transforma los datos de Spanner para que sean compatibles con el esquema de tu base de datos de origen con la herramienta de migración de Spanner. Para obtener más información, consulta Transformación personalizada.

  4. Verifica si la base de datos de origen ya contiene datos más recientes para la clave primaria especificada.

  5. Escribe los datos en tu base de datos de origen.

Usa la plantilla de Dataflow Spanner_to_SourceDb

La plantilla de Dataflow garantiza la coherencia a nivel de la clave primaria. La plantilla crea tablas de metadatos, conocidas como tablas paralelas, en Spanner que contienen la marca de tiempo de confirmación de la última transacción de escritura en la partición para esa tabla en particular.

La escritura es coherente hasta la marca de tiempo de confirmación de la clave primaria.

Puedes configurar el trabajo de Dataflow que realiza la replicación inversa para que se ejecute en uno de los siguientes modos:

  • Normal: Este es el modo predeterminado. El trabajo de Dataflow lee eventos de los flujos de cambios de Spanner, los convierte en tipos de datos compatibles con el esquema de la base de datos de origen y los aplica a la base de datos de origen. El trabajo reintenta automáticamente los errores. Después de agotar los reintentos, mueve los errores a la carpeta severe del directorio de la cola de mensajes no entregados (DLQ) en el bucket de Cloud Storage. El trabajo también mueve todos los errores permanentes a la carpeta severe.

  • RetryDLQ: En este modo, el trabajo de Dataflow lee eventos de la carpeta severe de la DLQ y los reintenta. Ejecuta este modo después de corregir todos los errores permanentes. En este modo, solo se lee desde la DLQ y no desde los flujos de cambios de Spanner. Si los registros procesados desde la carpeta severe se mueven a la carpeta retry, el trabajo vuelve a intentarlo.

Antes de comenzar

  • Asegúrate de que haya conectividad de red entre tu base de datos de MySQL de origen y tu proyecto deGoogle Cloud , en el que se ejecutarán tus trabajos de Dataflow.

  • Incluye en la lista de entidades permitidas las direcciones IP de los trabajadores de Dataflow en tu instancia de MySQL de destino.

  • Verifica que las credenciales de MySQL se especifiquen correctamente en source shards file.

  • Verifica que tu instancia de MySQL esté en línea y en ejecución.

  • Verifica que el usuario de MySQL tenga privilegios de INSERT, UPDATE y DELETE en la base de datos de MySQL.

  • Verifica que tengas los permisos de IAM necesarios para ejecutar una plantilla flexible de Dataflow. Para obtener más información, consulta Compila y ejecuta una plantilla flexible.

  • Verifica que el puerto 12345 esté abierto para la comunicación entre las VMs de los trabajadores de Dataflow.

Roles obligatorios

  • Para garantizar que la cuenta de servicio de Compute Engine tenga los permisos necesarios para iniciar la replicación inversa, pídele a tu administrador que le otorgue los siguientes roles de IAM a la cuenta de servicio de Compute Engine en la instancia:

Ejecuta la replicación inversa

Para ejecutar la replicación inversa, sigue estos pasos:

  1. Sube el archivo de sesión al bucket de Cloud Storage.

  2. Crea una notificación de Pub/Sub para la carpeta retry del directorio de la DLQ. Para ello, crea un tema de Pub/Sub y una suscripción de Pub/Sub para ese tema.

  3. Compila y almacena en etapa intermedia la plantilla de Dataflow. Para obtener más información, consulta Plantilla de compilación.

  4. Ejecuta la plantilla de Dataflow de replicación inversa con el siguiente comando de Google Cloud CLI:

      gcloud dataflow flex-template run "spanner-to-sourcedb-job" \
  --project "PROJECT" \
  --region "REGION" \
  --template-file-gcs-location "TEMPLATE_SPEC_GCSPATH" \
  --parameters "changeStreamName=CHANGE_STREAM_NAME" \
  --parameters "instanceId=INSTANCE_ID" \
  --parameters "databaseId=DATABASE_ID" \
  --parameters "spannerProjectId=SPANNER_PROJECT_ID" \
  --parameters "metadataInstance=METADATA_INSTANCE" \
  --parameters "metadataDatabase=METADATA_DATABASE" \
  --parameters "sourceShardsFilePath=SOURCE_SHARDS_FILE_PATH" \
  --parameters "startTimestamp=START_TIMESTAMP" \
  --parameters "endTimestamp=END_TIMESTAMP" \
  --parameters "shadowTablePrefix=SHADOW_TABLE_PREFIX" \
  [--parameters "sessionFilePath=SESSION_FILE_PATH"] \
  [--parameters "filtrationMode=FILTRATION_MODE"] \
  [--parameters "shardingCustomJarPath=SHARDING_CUSTOM_JAR_PATH"] \
  [--parameters "shardingCustomClassName=SHARDING_CUSTOM_CLASS_NAME"] \
  [--parameters "shardingCustomParameters=SHARDING_CUSTOM_PARAMETERS"] \
  [--parameters "sourceDbTimezoneOffset=SOURCE_DB_TIMEZONE_OFFSET"] \
  [--parameters "dlqGcsPubSubSubscription=DLQ_GCS_PUB_SUB_SUBSCRIPTION"] \
  [--parameters "skipDirectoryName=SKIP_DIRECTORY_NAME"] \
  [--parameters "maxShardConnections=MAX_SHARD_CONNECTIONS"] \
  [--parameters "deadLetterQueueDirectory=DEAD_LETTER_QUEUE_DIRECTORY"] \
  [--parameters "dlqMaxRetryCount=DLQ_MAX_RETRY_COUNT"] \
  [--parameters "runMode=RUN_MODE"] \
  [--parameters "dlqRetryMinutes=DLQ_RETRY_MINUTES"] \
  [--parameters "sourceType=SOURCE_TYPE"] \
  [--parameters "transformationJarPath=TRANSFORMATION_JAR_PATH"] \
  [--parameters "transformationClassName=TRANSFORMATION_CLASS_NAME"] \
  [--parameters "transformationCustomParameters=TRANSFORMATION_CUSTOM_PARAMETERS"] \
  [--parameters "filterEventsDirectoryName=FILTER_EVENTS_DIRECTORY_NAME"]

    Las variables obligatorias se describen en la siguiente lista:

    • project: Es el ID del proyecto de Google Cloud .
    • region: La Google Cloud región
    • template-file-gcs-location: Es la ruta de acceso al archivo de Cloud Storage en el que almacenaste la plantilla de Dataflow.
    • changeStreamName: Es el nombre del flujo de cambios de Spanner desde el que lee el trabajo.
    • instanceId: Es el ID de la instancia de Spanner.
    • databaseId: Es el ID de la base de datos de Spanner.
    • spannerProjectId: Es el ID del proyecto en el que residen tus instancias de Spanner.
    • metadataInstance: Es la instancia que almacena los metadatos que el conector usa para controlar el consumo de datos de la API de flujos de cambios.
    • metadataDatabase: Es la base de datos que almacena los metadatos que el conector usa para controlar el consumo de datos de la API de flujo de cambios.
    • sourceShardsFilePath: Es la ruta de acceso al archivo de Cloud Storage que contiene la información del perfil de conexión para las particiones de origen.

    Las variables opcionales se describen en la siguiente lista:

    • startTimestamp: Es la marca de tiempo a partir de la cual se comenzarán a leer los cambios. La configuración predeterminada es vacía.
    • endTimestamp: Es la marca de tiempo hasta la que se deben leer los cambios. Si no proporcionas una marca de tiempo, el proceso leerá los cambios de forma indefinida. El valor predeterminado es vacío.
    • shadowTablePrefix: Es el prefijo para nombrar las tablas paralelas. La configuración predeterminada es shadow_.
    • sessionFilePath: Es la ruta de acceso al archivo de sesión en Cloud Storage que contiene información de asignación de la herramienta de migración de Spanner.
    • filtrationMode: Es el modo que determina cómo filtrar los registros según los criterios. Los modos admitidos son none o forward_migration.
    • shardingCustomJarPath: Es la ubicación (ruta de acceso) en Cloud Storage del archivo JAR personalizado que contiene la lógica para recuperar el ID de fragmento. La configuración predeterminada es vacía.
    • shardingCustomClassName: Es el nombre de clase completamente calificado que tiene la implementación del ID de fragmento personalizado. Este campo es obligatorio si se especifica shardingCustomJarPath. La configuración predeterminada es vacía.
    • shardingCustomParameters: Es una cadena que contiene cualquier parámetro personalizado que se pasará a la clase de fragmentación personalizada. La configuración predeterminada es vacía.
    • sourceDbTimezoneOffset: Es la diferencia horaria entre la zona horaria UTC y la base de datos de origen. Ejemplo: +10:00. El valor predeterminado es +00:00.
    • dlqGcsPubSubSubscription: Es la suscripción a Pub/Sub que se usa en una política de notificaciones de Cloud Storage para el directorio de reintentos de DLQ cuando se ejecuta en modo regular. Especifica el nombre en el formato projects/<PROJECT_ID>/subscriptions/<SUBSCRIPTION_ID>. Cuando configuras este parámetro, el sistema ignora deadLetterQueueDirectory y dlqRetryMinutes.
    • skipDirectoryName: Es el directorio en el que el sistema escribe los registros que omite durante la replicación inversa. Predeterminado: skip.
    • maxShardConnections: Es la cantidad máxima de conexiones permitidas por fragmento. El valor predeterminado es 10,000.
    • deadLetterQueueDirectory: Es la ruta de acceso para almacenar el resultado de la DLQ. El valor predeterminado es un directorio en la ubicación temporal del trabajo de Dataflow.
    • dlqMaxRetryCount: Es la cantidad máxima de veces que el sistema reintenta los errores temporales a través de la DLQ. El valor predeterminado es 500.
    • runMode: Es el tipo de modo de ejecución. Las opciones son regular o retryDLQ. Usa retryDLQ para reintentar solo los registros graves de la DLQ. Valor predeterminado: regular.
    • dlqRetryMinutes: Es la cantidad de minutos entre reintentos de la DLQ. Cantidad predeterminada: 10.
    • sourceType: Es el tipo de base de datos de origen a la que se replicará de forma inversa. Valor predeterminado: mysql.
    • transformationJarPath: Es la ubicación (ruta de acceso) en Cloud Storage del archivo JAR personalizado que contiene la lógica de transformación personalizada para procesar registros en la replicación inversa. La configuración predeterminada es vacía.
    • transformationClassName: Es el nombre de clase completamente calificado que tiene la lógica de transformación personalizada. Este campo es obligatorio si se especifica transformationJarPath. La configuración predeterminada es vacía.
    • transformationCustomParameters: Es una cadena que contiene cualquier parámetro personalizado que se pasará a la clase de transformación personalizada. La configuración predeterminada es vacía.
    • filterEventsDirectoryName: Es el directorio en el que el sistema escribe los registros que omite durante la replicación inversa. Predeterminado: skip.

Próximos pasos