Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés. # Uso de una base de datos compatible con MySQL como fuente para AWS DMS Puede migrar datos desde cualquier base de datos compatible con MySQL (MySQL, MariaDB o Amazon Aurora MySQL) mediante Database Migration Service. AWS Para obtener información sobre las versiones de MySQL que se AWS DMS admiten como fuente, consulte[Fuentes de AWS DMS](CHAP_Introduction.Sources.md). Puede utilizar SSL para cifrar las conexiones entre su punto de enlace compatible con MySQL y la instancia de replicación. Para obtener más información acerca de cómo utilizar SSL con un punto de enlace compatible con MySQL, consulte [Uso de SSL con AWS Database Migration Service](CHAP_Security.SSL.md). En las secciones siguientes, el término “autoadministrado” se aplica a cualquier base de datos que se instala en las instalaciones o en Amazon EC2. El término “administrado por AWS” se aplica a cualquier base de datos en Amazon RDS, Amazon Aurora o Amazon S3. Para obtener información adicional sobre cómo trabajar con bases de datos compatibles con MySQL AWS DMS, consulte las siguientes secciones. **Topics** + [ ## Migración de MySQL a MySQL mediante AWS DMS ](#CHAP_Source.MySQL.Homogeneous) + [ ## Usar cualquier base de datos compatible con MySQL como fuente para AWS DMS ](#CHAP_Source.MySQL.Prerequisites) + [ ## Uso de una base de datos autogestionada compatible con MySQL como fuente para AWS DMS ](#CHAP_Source.MySQL.CustomerManaged) + [ ## Uso de una base AWS de datos compatible con MySQL administrada como fuente para AWS DMS ](#CHAP_Source.MySQL.AmazonManaged) + [ ## Limitaciones del uso de una base de datos MySQL como fuente para AWS DMS ](#CHAP_Source.MySQL.Limitations) + [ ## Compatibilidad con transacciones XA ](#CHAP_Source.MySQL.XA) + [ ## Configuración de punto final cuando se utiliza MySQL como fuente para AWS DMS ](#CHAP_Source.MySQL.ConnectionAttrib) + [ ## Tipos de datos de origen para MySQL ](#CHAP_Source.MySQL.DataTypes) **nota** Al configurar las reglas de mapeo AWS Database Migration Service (AWS DMS), es importante evitar el uso de caracteres comodín (%) en los nombres de bases de datos o esquemas. En su lugar, solo debe especificar de forma explícita las bases de datos creadas por los usuarios que deben migrarse. El uso de un carácter comodín incluye todas las bases de datos del proceso de migración, incluidas las bases de datos del sistema que no son necesarias en la instancia de destino. Como el usuario maestro de Amazon RDS para MySQL carece de los permisos necesarios para importar datos a las bases de datos del sistema de destino, se produce un error al intentar migrar estas bases de datos del sistema. ## Migración de MySQL a MySQL mediante AWS DMS Para una migración heterogénea, en la que se migra de un motor de base de datos distinto de MySQL a una base de datos MySQL, casi siempre AWS DMS es la mejor herramienta de migración que se puede utilizar. Sin embargo, para una migración homogénea, en la que se migra de una base de datos de MySQL a una base de datos de MySQL, le recomendamos que utilice un proyecto de migración de migraciones de datos homogéneas. Las migraciones de datos homogéneas utilizan herramientas de bases de datos nativas para proporcionar un rendimiento y una precisión de migración de datos mejorados en comparación con AWS DMS. ## Usar cualquier base de datos compatible con MySQL como fuente para AWS DMS Antes de empezar a trabajar con una base de datos MySQL como fuente AWS DMS, asegúrese de cumplir los siguientes requisitos previos. Estos requisitos previos se aplican a las fuentes autogestionadas o AWS gestionadas. Debe tener una cuenta AWS DMS que tenga la función de administrador de replicación. El rol necesita los siguientes privilegios: + **REPLICATION CLIENT**: este privilegio es necesario solo para tareas de CDC. En otras palabras, full-load-only las tareas no requieren este privilegio. **nota** Para MariaDB versión 10.5.2\$1, puede usar BINLOG MONITOR, que reemplaza al CLIENTE DE REPLICACIÓN. + **REPLICATION SLAVE**: este privilegio es necesario solo para tareas de CDC. En otras palabras, las full-load-only tareas no requieren este privilegio. + **SUPER**: este privilegio es necesario únicamente en versiones de MySQL anteriores a la 5.6.6. El AWS DMS usuario también debe tener privilegios SELECT para las tablas de origen designadas para la replicación. Otorgue los siguientes privilegios si utiliza evaluaciones previas a la migración específicas de MySQL: ``` grant select on mysql.user to ; grant select on mysql.db to ; grant select on mysql.tables_priv to ; grant select on mysql.role_edges to #only for MySQL version 8.0.11 and higher grant select on performance_schema.replication_connection_status to ; #Required for primary instance validation - MySQL version 5.7 and higher only ``` Si utiliza una fuente de RDS y planea ejecutar evaluaciones previas a la migración específicas de MySQL, añada el siguiente permiso: ``` grant select on mysql.rds_configuration to ; #Required for binary log retention check ``` Si el parámetro `BatchEnable` es `true` es obligatorio conceder: ``` grant create temporary tables on ``.* to ; ``` ## Uso de una base de datos autogestionada compatible con MySQL como fuente para AWS DMS Puede utilizar las siguientes bases de datos compatibles con MySQL autoadministradas como orígenes para AWS DMS: + MySQL Community Edition + MySQL Standard Edition + MySQL Enterprise Edition + MySQL Cluster Carrier Grade Edition + MariaDB Community Edition + MariaDB Enterprise Edition + Column Store de MariaDB Para usar CDC, asegúrese de habilitar el registro binario. Para habilitar el registro binario, se deben configurar los siguientes parámetros en el archivo de MySQL `my.ini` (Windows) o `my.cnf` (UNIX). | Parámetro | Valor | | --- | --- | | `server_id` | Establezca este parámetro con un valor de 1 o superior. | | `log-bin` | Establezca la ruta del archivo de registro binario, como por ejemplo `log-bin=E:\MySql_Logs\BinLog`. No incluya la extensión del archivo. | | `binlog_format` | Establezca este parámetro en `ROW`. Recomendamos esta configuración durante la replicación porque, en determinados casos, cuando `binlog_format` se establece en `STATEMENT`, puede provocar incoherencias al replicar los datos en el destino. El motor de base de datos también escribe datos similares e incoherentes en el destino cuando `binlog_format` está establecido en `MIXED`, ya que el motor de base de datos cambia automáticamente al registro basado en `STATEMENT` que puede resultar en datos incoherentes de escritura en la base de datos de destino. | | `expire_logs_days` | Establezca este parámetro con un valor de 1 o superior. Para evitar la sobrecarga de espacio en disco, se recomienda que no utilice el valor 0, que es el predeterminado. | | `binlog_checksum` | Establezca este parámetro en `NONE` para la versión 3.4.7 o anteriores de DMS. | | `binlog_row_image` | Establezca este parámetro en `FULL`. | | `log_slave_updates` | Establezca este parámetro en `TRUE` si está utilizando una réplica de lectura de MySQL o MariaDB como origen. | Si utiliza una réplica de lectura de MySQL o MariaDB como origen de una tarea de migración de DMS con el modo **Migrar los datos existentes y replicar los cambios continuos**, existe la posibilidad de pérdida de datos. DMS no escribirá una transacción durante la carga completa o la captura de datos de cambio en las siguientes condiciones: + La transacción se había confirmado en la instancia principal antes de que se iniciara la tarea de DMS. + La transacción no se había confirmado en la réplica hasta que se inició la tarea de DMS, debido al desfase entre la instancia principal y la réplica. Cuanto mayor sea el intervalo entre la instancia principal y la réplica, mayor será la posibilidad de pérdida de datos. Si su origen utiliza el motor de base de datos NDB (agrupado), deben configurarse los siguientes parámetros para habilitar la CDC en tablas que utilicen ese motor de almacenamiento. Agregue estos cambios al archivo de MySQL `my.ini` (Windows) o `my.cnf` (UNIX). | Parámetro | Valor | | --- | --- | | `ndb_log_bin` | Establezca este parámetro en `ON`. Este valor garantiza que los cambios en las tablas en clúster se anotan en los registros binarios. | | `ndb_log_update_as_write` | Establezca este parámetro en `OFF`. Este valor impide escribir instrucciones UPDATE como instrucciones INSERT en el registro binario. | | `ndb_log_updated_only` | Establezca este parámetro en `OFF`. Este valor garantiza que el registro binario contiene la totalidad de la fila y no solo las columnas que se han modificado. | ## Uso de una base AWS de datos compatible con MySQL administrada como fuente para AWS DMS Puede utilizar las siguientes bases de datos AWS gestionadas compatibles con MySQL como fuentes para: AWS DMS + MySQL Community Edition + MariaDB Community Edition + Amazon Aurora MySQL-Compatible Edition Cuando utilice como fuente una base AWS de datos gestionada compatible con MySQL AWS DMS, asegúrese de cumplir los siguientes requisitos previos para los CDC: + Para habilitar los registros binarios de RDS para MySQL y para RDS para MariaDB, habilite las copias de seguridad automáticas en el nivel de instancia. Para habilitar los registros binarios para un clúster de Aurora MySQL, cambie la variable `binlog_format` en el grupo de parámetros. Para obtener más información sobre la configuración de copias de seguridad automáticas, consulte [Trabajo con copias de seguridad automáticas](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.html) en la *Guía del usuario de Amazon RDS*. Para obtener más información sobre la configuración del registro binario para una base de datos de Amazon RDS para MySQL, consulte [Configuración del formato de registro binario](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.MySQL.BinaryFormat.html) en la *Guía del usuario de Amazon RDS*. Para obtener más información sobre la configuración del registro binario para un clúster de Aurora MySQL, consulte [¿Cómo activo el registro binario para mi clúster de Amazon Aurora MySQL?](https://aws.amazon.com/premiumsupport/knowledge-center/enable-binary-logging-aurora/). + Si piensa usar CDC, active el registro binario. Para obtener más información sobre la configuración del registro binario para una base de datos de Amazon RDS para MySQL, consulte [Configuración del formato de registro binario](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_LogAccess.MySQL.BinaryFormat.html) en la *Guía del usuario de Amazon RDS*. + Asegúrese de que los registros binarios estén disponibles para. AWS DMS Dado que las bases de datos AWS administradas compatibles con MySQL purgan los registros binarios lo antes posible, debe aumentar el tiempo que los registros permanecen disponibles. Por ejemplo, para incrementar la retención de logs a 24 horas, ejecute el siguiente comando. ``` call mysql.rds_set_configuration('binlog retention hours', 24); ``` + Establezca el parámetro `binlog_format` como `"ROW"`. **nota** En MySQL o MariaDB, `binlog_format` es un parámetro dinámico, por lo que no es necesario reiniciar el sistema para que el nuevo valor surta efecto. Sin embargo, el nuevo valor solo se aplicará a las sesiones nuevas. Si cambia `binlog_format` a `ROW` con fines de replicación, la base de datos puede seguir creando registros binarios posteriores con el mismo formato `MIXED`, si esas sesiones se iniciaron antes de que cambiara el valor. Esto puede impedir que se capturen correctamente todos AWS DMS los cambios en la base de datos de origen. Al cambiar la configuración de `binlog_format` en una base de datos de MariaDB o MySQL, asegúrese de reiniciar la base de datos para cerrar todas las sesiones existentes o de reiniciar cualquier aplicación que realice operaciones de DML (lenguaje de manipulación de datos). Obligar a la base de datos a reiniciar todas las sesiones después de cambiar el `binlog_format` parámetro `ROW` garantizará que la base de datos escriba todos los cambios posteriores en la base de datos de origen con el formato correcto, de forma que AWS DMS pueda capturar esos cambios correctamente. + Establezca el parámetro `binlog_row_image` como `"Full"`. + Establezca el parámetro `binlog_checksum` en `"NONE"` para la versión 3.4.7 o anteriores de DMS. Para obtener más información acerca de la configuración de parámetros en Amazon RDS MySQL, consulte [Trabajo con copias de seguridad automatizadas](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_WorkingWithAutomatedBackups.html) en la *Guía del usuario de Amazon RDS*. + Si utiliza una réplica de lectura de Amazon RDS MySQL o Amazon RDS MariaDB como origen, habilite las copias de seguridad en la réplica de lectura y asegúrese de que el parámetro `log_slave_updates` esté establecido en `TRUE`. ## Limitaciones del uso de una base de datos MySQL como fuente para AWS DMS Cuando utilice una base de datos MySQL como origen, tenga en cuenta lo siguiente: + No se admite la captura de datos de cambios (CDC) para Amazon RDS MySQL 5.5 o inferior. Para MySQL de Amazon RDS, debe usar la versión 5.6, 5.7 u 8.0 para habilitar CDC. CDC es compatible con orígenes MySQL 5.5 autoadministrados. + Para CDC, se admiten `CREATE TABLE`, `ADD COLUMN` y `DROP COLUMN` que cambian el tipo de datos de columna y `renaming a column`. Sin embargo, no se admiten `DROP TABLE`, `RENAME TABLE` y las actualizaciones realizadas en otros atributos, como el valor predeterminado de la columna, la nulabilidad de la columna, el conjunto de caracteres, etc. + En el caso de las tablas particionadas en el origen, al configurar el **modo de preparación** de **tablas de destino en Drop tables on target**, AWS DMS crea una tabla sencilla sin particiones en el destino de MySQL. Para migrar tablas con particiones a una tabla particionada en el destino, cree previamente las tablas con particiones en la base de datos de MySQL de destino. + Los objetivos relacionales no admiten el uso de una `ALTER TABLE table_name ADD COLUMN column_name` sentencia para añadir columnas al principio (FIRST) o al centro de una tabla (AFTER). Las columnas siempre se añaden al final de la tabla. Cuando el destino es Amazon S3 o Amazon Kinesis Data Streams, se admite la adición de columnas mediante FIRST o AFTER. + No se admite la CDC cuando un nombre de tabla contiene mayúsculas y minúsculas y el motor de origen está alojado en un sistema operativo con nombres de archivo que no distinguen entre mayúsculas y minúsculas. Un ejemplo es Microsoft Windows u OS X con HFS\$1. + Puede usar la edición compatible con MySQL de Aurora sin servidor versión 1 para la carga completa, pero no puede usarla para CDC. Esto se debe a que no se pueden habilitar los requisitos previos de MySQL. Para obtener más información, consulte [Grupos de parámetros y Aurora sin servidor v1](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-serverless.how-it-works.html#aurora-serverless.parameter-groups). La versión 2 de la edición compatible con MySQL de Aurora sin servidor admite CDC. + El atributo AUTO\$1INCREMENT en una columna no se migra a una columna de la base de datos de destino. + No se admite la captura de los cambios cuando los registros binarios no se almacenan en almacenamiento de bloques estándar. Por ejemplo, CDC no funciona cuando los registros binarios se almacenan en Amazon S3. + AWS DMS crea tablas de destino con el motor de almacenamiento InnoDB de forma predeterminada. Si necesita utilizar un motor de almacenamiento distinto de InnoDB, debe crear manualmente la tabla y migrar a ella mediante el modo [no hacer nada](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_GettingStarted.html). + No puede utilizar réplicas de Aurora MySQL como fuente a AWS DMS menos que su modo de tarea de migración de DMS sea **Migrar datos existentes**, solo a carga completa. + Si el origen compatible con MySQL se detiene durante la carga completa, la tarea de AWS DMS no se detiene con un error. La tarea finaliza correctamente, pero es posible que el destino no esté sincronizado con el origen. Si esto ocurre, reinicie la tarea o vuelva a cargar las tablas afectadas. + Los índices creados en una parte del valor de una columna no se migran. Por ejemplo, el índice CREATE INDEX first\$1ten\$1chars ON customer (name(10)) no se crea en el destino. + En algunos casos, la tarea está configurada para no replicarse LOBs (SupportLobs«» es falsa en la configuración de la tarea o se selecciona **No incluir columnas LOB** en la consola de tareas). En estos casos, AWS DMS no migra ninguna columna MEDIUMBLOB, LONGBLOB, MEDIUMTEXT ni LONGTEXT al destino. Las columnas BLOB, TINYBLOB, TEXT y TINYTEXT no se ven afectadas y se migran al destino. + Tablas o sistemas de datos temporales: las tablas de versión no son compatibles con las bases de datos de origen y destino de MariaDB. + Si migra entre dos clústeres Aurora MySQL de Amazon RDS, el punto de enlace de origen de Aurora MySQL de RDS debe ser read/write una instancia, no una instancia de réplica. + AWS DMS actualmente no admite la migración de vistas para MariaDB. + AWS DMS no admite cambios de DDL para tablas particionadas para MySQL. Para omitir la suspensión de tablas por cambios de DDL de particiones durante la CDC, establezca `skipTableSuspensionForPartitionDdl` en `true`. + AWS DMS solo admite transacciones XA en la versión 3.5.0 y versiones posteriores. Las versiones anteriores no admiten transacciones XA. AWS DMS no admite transacciones XA en la versión 10.6 o superior de MariaDB. Para obtener más información, consulte lo siguiente. [Compatibilidad con transacciones XA](#CHAP_Source.MySQL.XA) + AWS DMS no se utiliza GTIDs para la replicación, incluso si los datos de origen los contienen. + AWS DMS no es compatible con el registro binario mejorado de Aurora MySQL. + AWS DMS no admite la compresión de transacciones de registros binarios. + AWS DMS no propaga los eventos ON DELETE CASCADE y ON UPDATE CASCADE para bases de datos MySQL mediante el motor de almacenamiento InnoDB. Para estos eventos, MySQL no genera eventos binlog que reflejen las operaciones en cascada en las tablas secundarias. Por lo tanto, no AWS DMS puede replicar los cambios correspondientes en las tablas secundarias. Para obtener más información, consulte [Los índices, las claves externas o las actualizaciones o eliminaciones en cascada no se migran](CHAP_Troubleshooting.md#CHAP_Troubleshooting.MySQL.FKsAndIndexes). + AWS DMS no captura los cambios en las columnas calculadas (`VIRTUAL`y`GENERATED ALWAYS`). Para evitar esta limitación, haga lo siguiente: + Cree previamente la tabla de destino en la base de datos de destino y cree la tarea de AWS DMS con la configuración de tareas de carga completa `DO_NOTHING` o `TRUNCATE_BEFORE_LOAD`. + Agregue una regla de transformación para eliminar la columna calculada del ámbito de la tarea. Para obtener información sobre las reglas de transformación, consulte [Reglas y acciones de transformación](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.md). + Debido a la limitación interna de MySQL, BINLOGs no AWS DMS puede procesar un tamaño superior a 4 GB. BINLOGs Un tamaño superior a 4 GB puede provocar fallos en las tareas del DMS u otros comportamientos impredecibles. Debe reducir el tamaño de las transacciones para evitar que superen los BINLOGs 4 GB. + AWS DMS no admite comillas invertidas (```) ni comillas simples (`'`) en los nombres de esquemas, tablas y columnas. + AWS DMS no migra los datos de las columnas invisibles de la base de datos de origen. Para incluir estas columnas en el ámbito de la migración, use la instrucción ALTER TABLE para hacer visibles estas columnas. ## Compatibilidad con transacciones XA Una transacción de arquitectura ampliada (XA) es una transacción que se puede usar para agrupar una serie de operaciones de varios recursos transaccionales en una sola transacción global fiable. Una transacción XA utiliza un protocolo de confirmación en dos fases. En general, la captura de cambios mientras hay transacciones XA abiertas puede provocar la pérdida de datos. Si la base de datos no utiliza transacciones XA, puede ignorar este permiso y la configuración `IgnoreOpenXaTransactionsCheck` mediante el uso del valor predeterminado `TRUE`. Para empezar a replicar desde un origen que tiene transacciones XA, haga lo siguiente: + Asegúrese de que el usuario del AWS DMS punto final tenga el siguiente permiso: ``` grant XA_RECOVER_ADMIN on *.* to 'userName'@'%'; ``` + Establezca la configuración del punto de conexión `IgnoreOpenXaTransactionsCheck` en `false`. **nota** AWS DMS no admite transacciones XA en MariaDB Source DB versión 10.6 o superior. ## Configuración de punto final cuando se utiliza MySQL como fuente para AWS DMS Puede utilizar la configuración de punto de conexión para configurar la base de datos de origen de MySQL de forma similar al uso de atributos de conexión adicionales. Los ajustes se especifican al crear el punto final de origen mediante la AWS DMS consola o mediante el `create-endpoint` comando de [AWS CLI](https://docs.aws.amazon.com/cli/latest/reference/dms/index.html), con la sintaxis `--my-sql-settings '{"EndpointSetting": "value", ...}'` JSON. La siguiente tabla muestra la configuración de punto de conexión que puede utilizar con MySQL como origen. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/dms/latest/userguide/CHAP_Source.MySQL.html) ## Tipos de datos de origen para MySQL La siguiente tabla muestra los tipos de datos de origen de la base de datos MySQL que se admiten cuando se utilizan AWS DMS y la asignación predeterminada de AWS DMS los tipos de datos. Para obtener más información sobre cómo ver el tipo de datos que se asigna en el destino, consulte la sección del punto de enlace de destino que esté utilizando. Para obtener información adicional sobre AWS DMS los tipos de datos, consulte[Tipos de datos de AWS Database Migration Service](CHAP_Reference.DataTypes.md). | Tipos de datos de MySQL | AWS DMS tipos de datos | | --- | --- | | INT | INT4 | | BIGINT | INT8 | | MEDIUMINT | INT4 | | TINYINT | INT1 | | SMALLINT | INT2 | | UNSIGNED TINYINT | UINT1 | | UNSIGNED SMALLINT | UINT2 | | UNSIGNED MEDIUMINT | UINT4 | | UNSIGNED INT | UINT4 | | UNSIGNED BIGINT | UINT8 | | DECIMAL (10) | NUMERIC (10,0) | | BINARIO | BYTES(1) | | BIT | BOOLEANO | | BIT(64) | BYTES(8) | | BLOB | BYTES(65535) | | LONGBLOB | BLOB | | MEDIUMBLOB | BLOB | | TINYBLOB | BYTES(255) | | DATE | DATE | | DATETIME | DATETIME DATETIME sin un valor entre paréntesis se replica sin milisegundos. DATETIME con un valor entre paréntesis de 1 a 5 (como `DATETIME(5)`) se replica con milisegundos. Al replicar una columna DATETIME, la hora sigue siendo la misma en el destino. No se convierte a UTC. | | TIME | STRING | | TIMESTAMP | DATETIME Al replicar una columna TIMESTAMP, la hora se convierte a UTC en el destino. | | YEAR | INT2 | | DOUBLE | REAL8 | | FLOAT | REAL(DOUBLE) Si los valores FLOAT no están en el rango siguiente, use una transformación para asignar FLOAT a STRING. Para obtener más información sobre transformaciones, consulte [Reglas y acciones de transformación](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.md). El rango FLOAT admitido es de -1.79E\$1308 a -2.23E-308, 0 y de 2.23E-308 a 1.79E\$1308 | | VARCHAR (45) | WSTRING (45) | | VARCHAR (2000) | WSTRING (2000) | | VARCHAR (4000) | WSTRING (4000) | | VARBINARY (4000) | BYTES (4000) | | VARBINARY (2000) | BYTES (2000) | | CHAR | WSTRING | | TEXT | WSTRING | | LONGTEXT | NCLOB | | MEDIUMTEXT | NCLOB | | TINYTEXT | WSTRING(255) | | GEOMETRY | BLOB | | POINT | BLOB | | LINESTRING | BLOB | | POLYGON | BLOB | | MULTIPOINT | BLOB | | MULTILINESTRING | BLOB | | MULTIPOLYGON | BLOB | | GEOMETRYCOLLECTION | BLOB | | ENUM | CADENA () *length* Aquí, *length* es la longitud del valor más largo de la ENUM. | | SET | CADENA () *length* Aquí, *length* es la longitud total de todos los valores del SET, incluidas las comas. | | JSON | CLOB | **nota** En algunos casos, puede especificar los tipos de datos DATETIME y TIMESTAMP con un valor “cero” (es decir, 00-00-0000). Si es así, asegúrese de que la base de datos de destino de la tarea de replicación admita valores “cero” para los tipos de datos DATETIME y TIMESTAMP. De lo contrario, estos valores se registran con un valor NULL en el destino.