Transmite datos desde bases de datos de MySQL

Datastream te permite replicar datos históricos y cambios continuos de una base de datos de MySQL de origen en tu destino para realizar análisis en tiempo real y sincronizar la base de datos.

Antes de configurar una fuente de MySQL, revisa el comportamiento de la replicación, las versiones y los tipos de bases de datos compatibles, las prácticas recomendadas y las limitaciones conocidas en Datastream.

Comportamiento

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

Replicación basada en binlog

Datastream puede usar archivos de registro binario para mantener un registro de los cambios de datos en las bases de datos de MySQL. La información que contienen 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 binlog en Datastream son las siguientes:

  • Se pueden seleccionar todas las bases de datos o 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 las eliminaciones de las bases de datos y tablas especificadas.
  • Solo se replican los cambios confirmados.

Replicación basada en un 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 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 en todos los servidores de una topología de replicación determinada, a diferencia de la replicación basada en registros binarios, en la que cada nodo del clúster de la base de datos mantiene sus propios archivos binlog, con su propia numeración. Mantener archivos binlog y numeraciones independientes puede convertirse en un problema en caso de una falla o un 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, clústeres de bases de datos autoadministradas y sigue funcionando independientemente de los cambios en el clúster de la base 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 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 las eliminaciones de las bases de datos y tablas especificadas.
  • Solo se replican los cambios confirmados.
  • Compatibilidad sin interrupciones para conmutaciones por error

Cambia de la replicación basada en binlog a la basada en GTID

Si deseas actualizar tu transmisión y cambiar de la replicación basada en binlog a la 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 un flujo de prueba basado en GTID. 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. Detén la transmisión existente basada en binlog. Para obtener más información, consulta Pausa la transmisión.
  6. Espera unos minutos para asegurarte de que Datastream se haya puesto al día con la base de datos. Puedes verificar esto con las métricas de la pestaña Supervisión, en la página Detalles de la transmisión de tu transmisión. Los valores de Actualidad de los datos y Capacidad de procesamiento deben ser 0.
  7. Inicia la transmisión basada en GTID. Para obtener más información, consulta Inicia 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 se admite para la replicación basada en GTID)

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

Prácticas recomendadas

En esta sección, se describen las prácticas recomendadas para configurar tu fuente de MySQL y usarla con Datastream.

Usa GTID para configuraciones de alta disponibilidad

Si tu fuente de MySQL de producción usa réplicas o cualquier otra configuración de alta disponibilidad, usa la replicación basada en GTID.

La replicación basada en la posición y el archivo binlog puede interrumpirse durante una conmutación por error de la base de datos, ya que, cuando falla la instancia principal, la nueva instancia principal tiene un historial de binlog diferente. En ese caso, Datastream pierde su posición y no puede reanudarse.

El GTID asigna un ID único a cada transacción en toda la topología de replicación (principal y réplicas). Después de una conmutación por error, Datastream puede reanudar desde el último GTID registrado en la nueva instancia principal, sin necesidad de conocer el archivo binlog ni la posición.

Recomendación: Para cualquier fuente de MySQL de producción con una réplica o una configuración de alta disponibilidad, es obligatorio usar el método de CDC de GTID para una replicación de datos resiliente y confiable.

Ajusta el tamaño de tu réplica de lectura de forma adecuada

Si configuras Datastream para que se replique desde una réplica de lectura, puedes encontrarte con un retraso doble, que es una combinación del retraso de replicación de MySQL (desde la instancia principal hasta la réplica) y el retraso de replicación de Datastream (desde la réplica hasta el destino). Las réplicas de lectura suelen aprovisionarse con menos recursos (CPU, RAM, IOPS) que las principales para ahorrar costos, lo que puede hacer que se retrasen con respecto a la principal durante los períodos de alta escritura.

Recomendación: Cuando uses una réplica de lectura como fuente para Datastream, aprovisiónala con recursos comparables a los de la instancia principal para que la réplica pueda mantenerse al día con la capacidad de procesamiento de escritura de la instancia principal.

Aumenta la capacidad de procesamiento para el método de CDC de binlog

Si usas la replicación basada en binlog y experimentas una latencia alta debido a los grandes volúmenes de escritura de origen que generan archivos binlog más rápido de lo que puede procesar una sola tarea, aumenta la capacidad de procesamiento ajustando el parámetro maxConcurrentCdcTasks. Este parámetro controla la cantidad de tareas de CDC que una transmisión ejecuta en paralelo. Aumentar el valor de este parámetro permite que Datastream procese más archivos binlog de forma simultánea.

Recomendación: Para determinar el valor adecuado de la actualidad de los datos, supervisa la tasa de generación de binlog de tu servidor de MySQL durante las horas pico. Para ello, observa la velocidad con la que se crean y rotan los archivos binlog nuevos en el directorio de datos de MySQL, o usa las herramientas de supervisión de MySQL para hacer un seguimiento del crecimiento de los registros binarios. Por ejemplo, si tu fuente genera 10 archivos binlog por minuto durante las horas pico, establecer maxConcurrentCdcTasks en un valor como 10-15 permite que Datastream procese estos archivos en paralelo, lo que evita un retraso.

Puedes aumentar maxConcurrentCdcTasks hasta el valor máximo admitido de 50, siempre que la carga en la base de datos de origen permanezca bajo control. Para obtener más información, consulta Controles de simultaneidad de transmisiones.

Asigna el tamaño correcto al parámetro max_allowed_packet

La configuración predeterminada de max_allowed_packet en MySQL (por ejemplo, 16 MB-64 MB) podría ser demasiado pequeña. Si una sola fila con campos de tipo BLOB, JSON o TEXT grandes, o una sola transacción grande supera este tamaño, MySQL finaliza la conexión de Datastream, lo que hace que la transmisión falle con errores como Packet for query is too large o Got a packet bigger than 'max_allowed_packet' bytes.

Recomendación: Establece el parámetro max_allowed_packet en tu servidor de MySQL en su valor máximo permitido de 1G. Esto garantiza que el servidor pueda controlar cualquier fila o transacción grande que Datastream deba leer del binlog.

Limitaciones conocidas

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

  • Las transmisiones están limitadas a 10,000 tablas.
  • Las tablas replicadas deben usar el motor de almacenamiento InnoDB. Las tablas que usan el motor de almacenamiento MyISAM no son compatibles y no pasan la validación de transmisión.
  • No se pueden reabastecer las tablas que tienen una clave primaria definida como INVISIBLE.
  • Una tabla que tiene más de 500 millones de filas no se puede reabastecer, a menos que se cumplan las siguientes condiciones:
    1. La tabla tiene un índice único.
    2. Ninguna de las columnas del índice puede ser nula.
    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 un esquema cambia, 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 de esquemas, 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
    • Descartar tablas (relevante si la misma tabla se vuelve a crear con datos nuevos agregados)
    • Truncar tablas
  • Datastream no admite la replicación de vistas.
  • Datastream no admite columnas de tipos de datos espaciales, por ejemplo, GEOMETRY, POINT, LINESTRING, POLYGON. Los valores de estas columnas se reemplazan por valores 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 incluyan 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 archivos de registro binario de más de 4 GiB. Debido a que MySQL escribe cada transacción en un solo archivo de registro binario, mantén las transacciones individuales por debajo de 4 GiB para que los archivos de registro binario no superen este límite.
  • Datastream no admite cadenas de certificados SSL en los perfiles de conexión de MySQL de origen. Solo se admiten certificados individuales con codificación PEM x509.
  • Datastream no admite operaciones en cascada: ON UPDATE CASCADE ni ON DELETE CASCADE. Estos eventos no se escriben en el registro binario y, como resultado, no se propagan al destino. Como solución alternativa, puedes reemplazar las operaciones en cascada por activadores de base de datos.
  • Datastream no admite operaciones DROP PARTITION. Estas operaciones son solo de metadatos y no se replican. Los demás eventos no se ven afectados y la transmisión se ejecuta correctamente.
  • Es posible que experimentes problemas de conectividad cuando repliques tablas de FEDERATED. Si eso sucede, quita todas las tablas FEDERATED de la configuración de la base de datos de origen y aumenta los valores de los parámetros connect_timeout, net_read_timeout y max_allowed_packet para mitigar los problemas de tiempo de espera durante el reabastecimiento.
  • Las instancias de Cloud SQL Enterprise Plus deben usar la replicación basada en GTID porque están sujetas a un mantenimiento con un tiempo de inactividad casi nulo. La replicación basada en registros binarios se interrumpe en las conmutaciones por error, por lo que recomendamos usar la replicación basada en GTID para los casos de uso de alta disponibilidad.
  • Para las versiones 8.0 y posteriores de MySQL, la variable binlog_row_value_options debe establecerse en un valor vacío. Esta es la configuración predeterminada para la mayoría de las versiones, pero para algunas, como las fuentes de MySQL en Oracle Cloud Infrastructure (OCI), debes establecerla de forma explícita. Para obtener más información, consulta Configura una base de datos de MySQL autoadministrada.
  • Datastream no admite transacciones distribuidas (XA). MySQL escribe eventos de transacciones XA en el registro binario cuando se ejecuta la sentencia XA PREPARE. Por lo tanto, los cambios de las transacciones de XA preparadas se replican en el destino, incluso si la transacción se revierte más adelante con una declaración XA ROLLBACK.
  • Limitaciones de MariaDB:
    • La replicación basada en GTID no es compatible con MariaDB. Debes configurar las transmisiones de MariaDB para usar la replicación basada en binlog.
    • Para las versiones de MariaDB de la 11.4 a la 12.2, debes habilitar la variable de sistema binlog_legacy_event_pos en la base de datos de origen para garantizar la compatibilidad con Datastream.
    • Datastream no admite el tipo de datos UUID (introducido en MariaDB 10.7). Debes excluir las columnas del tipo de datos UUID de la configuración de la transmisión.

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 declaraciones CREATE TABLE ... SELECT.
  • Datastream no admite GTID 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?