Configurar la alternativa para MySQL

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

La replicación inversa es útil cuando se producen problemas inesperados y necesitas volver a la base de datos MySQL original con la mínima interrupción del servicio. La replicación inversa te permite volver a la configuración anterior replicando los datos escritos en Spanner en tu base de datos MySQL de origen. De esta forma, ambas bases de datos serán coherentes.

El flujo de replicación inversa implica los siguientes pasos, que lleva a cabo la Spanner_to_SourceDbplantilla de Dataflow:

  1. Lee los cambios de Spanner mediante flujos de cambios de Spanner.

  2. Asegúrate de que el modo de filtración sea forward_migration.

  3. Transforma los datos de Spanner para que sean compatibles con el esquema de tu base de datos de origen mediante 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 principal especificada.

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

Usar la plantilla de Dataflow Spanner_to_SourceDb

La plantilla de Dataflow garantiza la coherencia a nivel de clave principal. La plantilla crea tablas de metadatos, conocidas como tablas de réplica, en Spanner que contienen la marca de tiempo de confirmación de la última transacción de escritura en el fragmento de esa tabla concreta.

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

Puede configurar la tarea de Dataflow que realiza la replicación inversa para que se ejecute en uno de los siguientes modos:

  • Normal: 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 vuelve a intentar automáticamente los errores. Después de agotar los reintentos, mueve los errores a la carpeta severe del directorio de la cola de mensajes fallidos (DLQ) en el segmento de Cloud Storage. El trabajo también mueve todos los errores permanentes a la carpeta severe.

  • RetryDLQ en este modo, la tarea de Dataflow lee los eventos de la carpeta severe de la cola de mensajes fallidos y vuelve a intentarlos. Ejecuta este modo después de corregir todos los errores permanentes. Este modo solo lee de la cola de mensajes fallidos y no de los flujos de cambios de Spanner. Si los registros procesados de la carpeta severe se mueven a la carpeta retry, la tarea vuelve a intentarlo.

Antes de empezar

  • Asegúrate de que haya conectividad de red entre tu base de datos MySQL de origen y tuGoogle Cloud proyecto, donde se ejecutarán tus tareas de Dataflow.

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

  • Comprueba que las credenciales de MySQL se hayan especificado correctamente en source shards file.

  • Comprueba que tu instancia de MySQL esté online y en funcionamiento.

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

  • Comprueba que tienes los permisos de gestión de identidades y accesos necesarios para ejecutar una plantilla flexible de Dataflow. Para obtener más información, consulta Crear y ejecutar una plantilla flexible.

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

Roles obligatorios

  • Para asegurarte de que la cuenta de servicio de Compute Engine tiene los permisos necesarios para iniciar la replicación inversa, pide a tu administrador que le conceda los siguientes roles de gestión de identidades y accesos en la instancia:

Ejecutar replicación inversa

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

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

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

  3. Crea y organiza la plantilla de Dataflow. Para obtener más información, consulta Crear plantillas.

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

      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: el ID del proyecto. Google Cloud
    • region: la Google Cloud región.
    • template-file-gcs-location: la ruta al archivo de Cloud Storage donde has almacenado la plantilla de Dataflow.
    • changeStreamName: el nombre del flujo de cambios de Spanner del que lee el trabajo.
    • instanceId: el ID de la instancia de Spanner.
    • databaseId: el ID de la base de datos de Spanner.
    • spannerProjectId: el ID del proyecto en el que residen tus instancias de Spanner.
    • metadataInstance: la instancia que almacena los metadatos que usa el conector para controlar el consumo de datos de la API de flujo de cambios.
    • metadataDatabase: la base de datos que almacena los metadatos que usa el conector para controlar el consumo de datos de la API de flujo de cambios.
    • sourceShardsFilePath: la ruta al archivo de Cloud Storage que contiene la información del perfil de conexión de los fragmentos de origen.

    Las variables opcionales se describen en la siguiente lista:

    • startTimestamp: la marca de tiempo a partir de la cual se deben leer los cambios. El valor predeterminado es una cadena vacía.
    • endTimestamp: la marca de tiempo hasta la que se deben leer los cambios. Si no proporcionas una marca de tiempo, el proceso leerá los cambios indefinidamente. El valor predeterminado es una cadena vacía.
    • shadowTablePrefix: el prefijo para asignar nombres a las tablas de sombra. El valor predeterminado es shadow_.
    • sessionFilePath: la ruta al archivo de sesión en Cloud Storage que contiene información de asignación de la herramienta de migración de Spanner.
    • filtrationMode: el modo que determina cómo filtrar los registros en función de los criterios. Los modos admitidos son none y forward_migration.
    • shardingCustomJarPath: la ubicación (ruta) en Cloud Storage del archivo JAR personalizado que contiene la lógica para obtener el ID de fragmento. El valor predeterminado es una cadena vacía.
    • shardingCustomClassName: el nombre de clase completo que tiene la implementación del ID de fragmento personalizado. Este campo es obligatorio si se especifica shardingCustomJarPath. El valor predeterminado es una cadena vacía.
    • shardingCustomParameters: una cadena que contiene los parámetros personalizados que se van a transferir a la clase de partición personalizada. El valor predeterminado es una cadena vacía.
    • sourceDbTimezoneOffset: la diferencia horaria con respecto al UTC de la base de datos de origen. Ejemplo: +10:00. Valor predeterminado: +00:00.
    • dlqGcsPubSubSubscription: la suscripción de Pub/Sub que se usa en una política de notificaciones de Cloud Storage para el directorio de reintentos de la cola de mensajes fallidos cuando se ejecuta en modo regular. Especifica el nombre con el formato projects/<PROJECT_ID>/subscriptions/<SUBSCRIPTION_ID>. Si defines este parámetro, el sistema ignorará deadLetterQueueDirectory y dlqRetryMinutes.
    • skipDirectoryName: el directorio en el que el sistema escribe los registros que omite durante la replicación inversa. Valor predeterminado: skip.
    • maxShardConnections: número máximo de conexiones permitidas por fragmento. Valor predeterminado: 10000.
    • deadLetterQueueDirectory: la ruta para almacenar la salida de la cola de mensajes fallidos. El valor predeterminado es un directorio de la ubicación temporal de la tarea de Dataflow.
    • dlqMaxRetryCount: número máximo de veces que el sistema vuelve a intentar corregir errores temporales a través de la cola de mensajes fallidos. Valor predeterminado: 500.
    • runMode: el tipo de modo de ejecución. Las opciones son regular o retryDLQ. Usa retryDLQ para volver a intentar solo los registros de DLQ graves. Valor predeterminado: regular.
    • dlqRetryMinutes: número de minutos entre reintentos de DLQ. Valor predeterminado: 10.
    • sourceType: el tipo de base de datos de origen a la que se va a replicar. Predeterminado: mysql.
    • transformationJarPath: la ubicación (ruta) en Cloud Storage del archivo JAR personalizado que contiene la lógica de transformación personalizada para procesar registros en la replicación inversa. El valor predeterminado es una cadena vacía.
    • transformationClassName: el nombre de clase completo que tiene la lógica de transformación personalizada. Este campo es obligatorio si se especifica transformationJarPath. El valor predeterminado es una cadena vacía.
    • transformationCustomParameters: cadena que contiene los parámetros personalizados que se van a transferir a la clase de transformación personalizada. El valor predeterminado es una cadena vacía.
    • filterEventsDirectoryName: el directorio en el que el sistema escribe los registros que omite durante la replicación inversa. Valor predeterminado: skip.

Siguientes pasos