Base de datos de MySQL de origen

En esta sección, se incluye información sobre lo siguiente:

  • El comportamiento de Datastream en el manejo de los datos que se extraen de una base de datos de MySQL de origen
  • Las versiones de la base de datos de MySQL que Datastream admite
  • Limitaciones conocidas del uso de la base de datos de MySQL como fuente
  • Una descripción general de cómo configurar una base de datos de MySQL de origen para que los datos se puedan transmitir a un destino

Comportamiento

En esta sección, se describe el comportamiento de las fuentes de MySQL cuando se replican datos con Datastream. Cuando transfieres datos desde bases de datos de MySQL, puedes usar la replicación basada en binlogs o la replicación basada en identificadores de transacciones globales (GTID). Seleccionas tu método de CDC cuando creas una transmisión.

Replicación basada en binlogs

Datastream puede usar archivos de registro binario para mantener un registro de los cambios de datos en las bases de datos de MySQL. Luego, la información contenida en estos archivos de registro se replica en el destino para reproducir los cambios realizados en la fuente.

Las características clave de la replicación basada en binlogs en Datastream son las siguientes:

  • Se pueden seleccionar todas las bases de datos o las bases de datos específicas de una fuente de MySQL determinada, así como todas las tablas de las bases de datos o tablas específicas.
  • Se replican todos los datos históricos.
  • Se replican todos los cambios del lenguaje de manipulación de datos (DML), como las inserciones, las actualizaciones y los borrados de las bases de datos y las tablas especificadas.
  • Solo se replican los cambios confirmados.

Replicación basada en identificador de transacciones global (GTID)

Datastream también admite la replicación basada en identificadores globales (GTID).

El identificador de transacciones global (GTID) es un identificador único que se crea y se asocia con cada transacción confirmada en una fuente de MySQL. Este identificador es único no solo para la fuente en la que se originó, sino también para todos los servidores en una topología de replicación determinada, a diferencia de la replicación basada en el registro binario, en la que cada nodo del clúster de la base de datos mantiene sus propios archivos de registro binario, con su propia numeración. Mantener archivos binlog separados y numerados puede convertirse en un problema en caso de falla o tiempo de inactividad planificado, ya que se interrumpe la continuidad del binlog y falla la replicación basada en binlog.

La replicación basada en GTID admite conmutaciones por error y clústeres de bases de datos autoadministradas, y sigue funcionando independientemente de los cambios en el clúster de bases de datos.

Las características clave de la replicación basada en GTID en Datastream son las siguientes:

  • Se pueden seleccionar todas las bases de datos o las bases de datos específicas de una fuente de MySQL determinada, así como todas las tablas de las bases de datos o tablas específicas.
  • Se replican todos los datos históricos.
  • Se replican todos los cambios del lenguaje de manipulación de datos (DML), como las inserciones, las actualizaciones y los borrados de las bases de datos y las tablas especificadas.
  • Solo se replican los cambios confirmados.
  • Compatibilidad perfecta con las conmutaciones por error

Cómo cambiar de la replicación basada en registros binarios a la replicación basada en GTID

Si deseas actualizar tu transmisión y cambiar de la replicación basada en binlogs a la replicación basada en GTID sin necesidad de realizar un reabastecimiento, sigue estos pasos:

  1. Asegúrate de que se cumplan todos los requisitos para la replicación basada en GTID. Para obtener más información, consulta Configura una base de datos de MySQL de origen.
  2. De manera opcional, crea y ejecuta una transmisión basada en el GTID de prueba. Para obtener más información, consulta Crea una transmisión.
  3. Crea una transmisión basada en GTID. No lo inicies todavía.
  4. Detén el tráfico de la aplicación a la base de datos de origen.
  5. Pausa la transmisión existente basada en el registro binario. Para obtener más información, consulta Cómo pausar la transmisión.
  6. Espera unos minutos para asegurarte de que Datastream se haya actualizado con la base de datos. Puedes verificarlo con las métricas de la pestaña Monitoring en la página Detalles del flujo de tu flujo. Los valores de Actualidad de los datos y Rendimiento deben ser 0.
  7. Inicia la transmisión basada en GTID. Para obtener más información, consulta Cómo iniciar la transmisión.
  8. Reanuda el tráfico a la base de datos de origen.

Si realizar un reabastecimiento no es un problema, puedes truncar tus tablas en BigQuery, borrar la transmisión anterior y comenzar una nueva con reabastecimiento. Para obtener más información sobre cómo administrar el reabastecimiento, consulta Administra el reabastecimiento de los objetos de una transmisión.

Versiones

Datastream admite las siguientes versiones de la base de datos de MySQL:

  • MySQL 5.6
  • MySQL 5.7
  • MySQL 8.0

  • MySQL 8.4 (solo compatible con la replicación basada en GTID)

Datastream admite los siguientes tipos de bases de datos de MySQL:

Limitaciones conocidas

Entre las limitaciones conocidas del uso de la base de datos MySQL como fuente, se incluyen las siguientes:

  • Las transmisiones se limitan a 10,000 tablas.
  • Las tablas que tienen una clave primaria definida como INVISIBLE no se pueden reabastecer.
  • No se puede completar una tabla que tenga más de 500 millones de filas, a menos que se cumplan las siguientes condiciones:
    1. La tabla tiene un índice único.
    2. Ninguna de las columnas del índice admite valores nulos.
    3. El índice no es descendente.
    4. Todas las columnas del índice se incluyen en la transmisión.
  • Datastream recupera periódicamente el esquema más reciente de la fuente a medida que se procesan los eventos. Si cambia un esquema, Datastream detecta el cambio y activa una recuperación del esquema. Sin embargo, es posible que algunos eventos se procesen de forma incorrecta o se descarten entre las recuperaciones del esquema, lo que puede causar discrepancias en los datos.
  • No todos los cambios en el esquema de origen se pueden detectar automáticamente, en cuyo caso pueden ocurrir daños en los datos. Los siguientes cambios de esquema pueden causar daños en los datos o que no se puedan procesar los eventos en etapas posteriores:
    • Descarta columnas
    • Agregar columnas en medio de una tabla
    • Cambiar el tipo de datos de una columna
    • Reordenar las columnas
    • Borrar tablas (relevante si luego se vuelve a crear la misma tabla con datos nuevos)
    • Truncar tablas
  • Datastream no admite la replicación de vistas.
  • Datastream no admite columnas de tipos de datos espaciales. Los valores de estas columnas se reemplazan por valores de NULL.
  • Datastream no admite el valor cero (0000-00-00 00:00:00) en las columnas de los tipos de datos DATETIME, DATE o TIMESTAMP. El valor cero se reemplaza por el valor NULL.
  • Datastream no admite la replicación de filas que incluyen los siguientes valores en las columnas JSON: DECIMAL, NEWDECIMAL, TIME, TIME2, DATETIME, DATETIME2, DATE, TIMESTAMP o TIMESTAMP2. Se descartan los eventos que contienen esos valores.
  • Datastream no admite la compresión de transacciones de registros binarios.
  • Datastream no admite cadenas de certificados SSL en los perfiles de conexión de MySQL de origen. Solo se admiten certificados únicos con codificación PEM x509.
  • Datastream no admite la eliminación en cascada. Estos eventos no se escriben en el registro binario y, como resultado, no se propagan al destino.
  • Datastream no admite operaciones de DROP PARTITION. Estas operaciones son solo de metadatos y no se replican. Otros eventos no se ven afectados y la transmisión se ejecuta correctamente.
  • Dado que Datastream no admite conmutaciones por error a réplicas cuando se usa la replicación basada en registros binarios, te recomendamos que uses la replicación basada en GTID para las fuentes de Cloud SQL para MySQL Enterprise Plus. Las instancias de Cloud SQL Enterprise Plus están sujetas a mantenimiento con tiempo de inactividad casi nulo y conmutan por error a una réplica durante el mantenimiento.

Limitaciones adicionales para la replicación basada en GTID

  • La recuperación de transmisiones que usan la replicación basada en GTID solo está disponible cuando se usa la API de Datastream.
  • No se admite la creación de tablas a partir de otras tablas con las instrucciones CREATE TABLE ... SELECT.
  • Datastream no admite GTIDs etiquetados.
  • Para conocer las restricciones de MySQL que se aplican a la replicación basada en GTID, consulta la documentación de MySQL.

¿Qué sigue?