Transmitir datos desde bases de datos MySQL

Esta sección contiene información sobre lo siguiente:

  • El comportamiento de Datastream al gestionar los datos que se extraen de una base de datos MySQL de origen
  • Versiones de la base de datos MySQL compatibles con Datastream
  • Limitaciones conocidas al usar una base de datos MySQL como origen
  • Resumen de cómo configurar una base de datos MySQL de origen para que los datos se puedan transmitir desde ella a un destino

Comportamiento

En esta sección se describe el comportamiento de las fuentes de MySQL cuando se replican datos con Datastream. Cuando ingieres datos de bases de datos MySQL, puedes usar la replicación basada en binlog o la replicación basada en el identificador de transacción global (GTID). Selecciona el método de CDC al crear un flujo.

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 MySQL. La información contenida en estos archivos de registro se replica en el destino para reproducir los cambios realizados en el origen.

Estas son las características principales de la replicación basada en binlog en Datastream:

  • Se pueden seleccionar todas las bases de datos o bases de datos específicas de un origen de MySQL determinado, 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 las tablas especificadas.
  • Solo se replican los cambios confirmados.

Replicación basada en el identificador de transacción global (GTID)

Datastream también admite la replicación basada en el identificador global (GTID).

El identificador de transacción global (GTID) es un identificador único que se crea y se asocia a cada transacción confirmada en una fuente de MySQL. Este identificador no solo es único para la fuente en la que se originó, sino también para 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 bases de datos mantiene sus propios archivos de registro binario, con su propia numeración. Mantener archivos binlog independientes y numerados puede suponer un problema en caso de fallo o de inactividad programada, ya que se interrumpe la continuidad de los binlogs y se produce un error en la replicación basada en binlogs.

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

Estas son las características principales de la replicación basada en GTID en Datastream:

  • Se pueden seleccionar todas las bases de datos o bases de datos específicas de un origen de MySQL determinado, 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 las tablas especificadas.
  • Solo se replican los cambios confirmados.
  • Compatibilidad perfecta con las conmutaciones por error.

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

Si quieres actualizar tu flujo y cambiar de la replicación basada en binlog a la basada en GTID sin tener que hacer un relleno, sigue estos pasos:

  1. Asegúrate de que se cumplen todos los requisitos para la replicación basada en GTID. Para obtener más información, consulta el artículo sobre cómo configurar una base de datos MySQL de origen.
  2. Opcionalmente, crea y ejecuta un flujo de prueba basado en GTID. Para obtener más información, consulta Crear un flujo.
  3. Crea un flujo basado en GTID. No lo inicies todavía.
  4. Detener el tráfico de aplicaciones a la base de datos de origen.
  5. Pausa el flujo basado en binlog. Para obtener más información, consulta Pausar la emisión.
  6. Espera unos minutos para asegurarte de que Datastream se ha puesto al día con la base de datos. Para comprobarlo, consulta las métricas de la pestaña Monitorización de la página Detalles del flujo. Los valores de Actualización de datos y Rendimiento deben ser 0.
  7. Inicia la réplica basada en GTID. Para obtener más información, consulta Iniciar la emisión.
  8. Reanuda el tráfico a la base de datos de origen.

Si no hay ningún problema en realizar un relleno, puedes truncar tus tablas en BigQuery, eliminar el flujo antiguo e iniciar uno nuevo con relleno. Para obtener más información sobre cómo gestionar el backfill, consulta Gestionar backfill para objetos de un flujo.

Versiones

Datastream admite las siguientes versiones de la base de datos 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 MySQL:

Prácticas recomendadas

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

Usar GTID en configuraciones de alta disponibilidad

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

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

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

Recomendación: En 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 que la replicación de datos sea resiliente y fiable.

Ajustar el tamaño de la réplica de lectura

Si configura Datastream para que replique datos de una réplica de lectura, puede experimentar un doble retraso, que es una combinación del retraso de la replicación de MySQL (de la principal a la réplica) y del retraso de la replicación de Datastream (de la réplica al destino). Las réplicas de lectura suelen aprovisionarse con menos recursos (CPU, RAM, IOPS) que las primarias para ahorrar costes, lo que puede provocar que se queden atrás con respecto a la primaria durante los periodos de escritura intensa.

Recomendación: Cuando utilices una réplica de lectura como fuente de Datastream, proporciónale recursos comparables a los de la réplica principal para que pueda mantener el ritmo del rendimiento de escritura de la réplica principal.

Aumentar el rendimiento del método CDC de binlog

Si usas la replicación basada en binlog y experimentas una latencia alta debido a que los grandes volúmenes de escritura de origen generan archivos binlog más rápido de lo que puede procesar una sola tarea, aumenta el rendimiento ajustando el parámetro maxConcurrentCdcTasks. Este parámetro controla el número de tareas de CDC que ejecuta un flujo en paralelo. Si aumenta el valor de este parámetro, Datastream podrá procesar más archivos de registro binario simultáneamente.

Recomendación: Para determinar el valor adecuado de la actualización de datos, monitoriza la tasa de generación de binlogs de tu servidor MySQL durante las horas punta. Para ello, puedes observar la frecuencia con la que se crean y se rotan los nuevos archivos binlog en el directorio de datos de MySQL o usar herramientas de monitorización de MySQL para hacer un seguimiento del crecimiento de los registros binarios. Por ejemplo, si su origen genera 10 archivos de registro binario por minuto durante las horas punta, al asignar a maxConcurrentCdcTasks un valor como 10-15, Datastream puede procesar estos archivos en paralelo, lo que evita que se acumulen.

Puedes aumentar maxConcurrentCdcTasks hasta el valor máximo admitido de 50, siempre que la carga de la base de datos de origen siga controlada. Para obtener más información, consulta Controles de simultaneidad de las emisiones.

Asigna el tamaño correcto al parámetro max_allowed_packet

El valor predeterminado de max_allowed_packet en MySQL (por ejemplo, de 16 a 64 MB) puede ser demasiado pequeño. Si una sola fila con campos de tipo BLOB, JSON o TEXT de gran tamaño, o una sola transacción de gran tamaño supera este límite, MySQL finalizará la conexión de Datastream, lo que provocará que la transmisión falle y se produzcan errores como Packet for query is too large o Got a packet bigger than 'max_allowed_packet' bytes.

Recomendación: defina el parámetro max_allowed_packet en su servidor MySQL con el valor máximo permitido, que es 1 GB. De esta forma, el servidor puede gestionar cualquier fila o transacción de gran tamaño que Datastream necesite leer del archivo de registro binario.

Limitaciones conocidas

Estas son algunas de las limitaciones conocidas al usar una base de datos MySQL como fuente:

  • Las secuencias tienen un límite de 10.000 tablas.
  • Las tablas que tienen una clave principal definida como INVISIBLE no se pueden rellenar.
  • No se puede rellenar 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 puede tener un valor nulo.
    3. El índice no es descendente.
    4. Todas las columnas del índice se incluyen en el flujo.
  • Datastream obtiene 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 obtención del esquema. Sin embargo, es posible que algunos eventos se procesen de forma incorrecta o se pierdan entre las solicitudes de esquemas, lo que puede provocar discrepancias en los datos.
  • No todos los cambios en el esquema de origen se pueden detectar automáticamente, por lo que puede que se produzcan daños en los datos. Los siguientes cambios en el esquema pueden provocar que los datos se dañen o que no se puedan procesar los eventos más adelante:
    • Eliminar columnas
    • Añadir columnas en medio de una tabla
    • Cambiar el tipo de datos de una columna
    • Reordenar columnas
    • Eliminar tablas (es relevante si la misma tabla se vuelve a crear con nuevos datos añadidos)
    • 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 sustituyen 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 sustituye 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. Los eventos que contengan estos valores se descartarán.
  • Datastream no admite la compresión de transacciones de registro binario.
  • Datastream no admite cadenas de certificados SSL en los perfiles de conexión de MySQL de origen. Solo se admiten certificados únicos x509 codificados en PEM.
  • Datastream no admite eliminaciones en cascada. Estos eventos no se escriben en el registro binario y, por lo tanto, no se propagan al destino.
  • Datastream no admite operaciones DROP PARTITION. Estas operaciones son solo de metadatos y no se replican. Otros eventos no se ven afectados y la emisión se ejecuta correctamente.
  • Es posible que tengas problemas de conectividad al replicar tablas de FEDERATED. Si esto ocurre, quite todas las tablas FEDERATED de la configuración de la base de datos de origen y aumente 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 relleno.
  • Las instancias de Cloud SQL Enterprise Plus deben usar la replicación basada en GTID porque están sujetas a mantenimiento con un tiempo de inactividad prácticamente 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 en los casos de uso de alta disponibilidad.
  • En las versiones 8.0 y posteriores de MySQL, la variable binlog_row_value_options debe tener un valor vacío. Este es el valor predeterminado para la mayoría de las versiones, pero en algunas, como las fuentes de MySQL en Oracle Cloud Infrastructure (OCI), debes definirlo explícitamente. Para obtener más información, consulta Configurar una base de datos MySQL autogestionada.

Limitaciones adicionales de la replicación basada en GTID

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

Siguientes pasos