Base de datos de MySQL de origen

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

  • El comportamiento de cómo Datastream controla los datos que se extraen de una base de datos MySQL de origen
  • Las versiones de la base de datos de MySQL que Datastream admite
  • Limitaciones conocidas para usar la base de datos 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

La base de datos de MySQL depende de su función de registro binario para exponer los cambios en los datos.

  • 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 en el lenguaje de manipulación de datos (DML), como las inserciones, actualizaciones y eliminaciones desde las bases de datos y tablas especificadas.
  • Solo se replican los cambios confirmados.

Versiones

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

  • MySQL 5.6
  • MySQL 5.7
  • MySQL 8.0

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

Limitaciones conocidas

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

  • Las transmisiones tienen un límite de 10,000 tablas.
  • 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. El índice no incluye columnas de los siguientes tipos: VARCHAR, NVARCHAR, CHAR.
    3. Ninguna de las columnas del índice es anulable.
    4. El índice no es descendente.
    5. Todas las columnas del índice se incluyen en el flujo.
  • Datastream recupera periódicamente el esquema más reciente de la fuente a medida que se procesan los eventos. Si se modifica 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
    • Eliminación de tablas (relevantes si la misma tabla se vuelve a crear tras agregar 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 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 tales 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 x509 con codificación PEM.
  • Datastream no admite eliminaciones en cascada. Esos eventos no se escriben en el registro binario y, como resultado, no se propagan al destino.
  • Datastream no admite conmutaciones por error a réplicas. Debido a esto, no recomendamos usar Datastream para la replicación desde fuentes de Cloud SQL para MySQL Enterprise Plus. Las instancias de la edición Enterprise Plus de Cloud SQL están sujetas a un mantenimiento de tiempo de inactividad casi nulo y se conmutan a una réplica durante el mantenimiento. Esto interrumpe la continuidad del binlog y, por lo tanto, las transmisiones afectadas fallan de forma permanente.