View a markdown version of this page

Utilizar una MySQL-compatible base de datos como fuente para AWS DMS - AWS Database Migration Service
Migraciones de MySQL a MySQLUso de MySQL como origenUso de MySQL autoadministrado como origenUsar MySQL AWS-managed como fuenteFuentes de Aurora MySQL 8.4Restricciones sobre MySQL como origenCompatibilidad con transacciones XAConfiguración del punto de conexiónTipos de datos de origen para MySQL

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.

Utilizar una MySQL-compatible base de datos como fuente para AWS DMS

Puede migrar datos de cualquier MySQL-compatible base de datos (MySQL, MariaDB o Amazon Aurora MySQL) mediante el servicio de migración de bases de datos. AWS

Para obtener información sobre las versiones de MySQL AWS DMS compatibles como fuente, consulte. Fuentes de AWS DMS

Puede usar SSL para cifrar las conexiones entre el MySQL-compatible punto final y la instancia de replicación. Para obtener más información sobre el uso de SSL con un MySQL-compatible punto final, consulteUso de SSL con AWS Database Migration Service.

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 más información sobre cómo trabajar con MySQL-compatible bases de datos AWS DMS, consulte las siguientes secciones.

nota

Al configurar las reglas de mapeo AWS Database Migration Service (AWS DMS), es importante evitar el uso de caracteres comodín (%) para 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.

Migrar de MySQL a MySQL usando AWS DMS

En el caso de una migración heterogénea, en la que se migra de un motor de base de datos que no sea MySQL a una base de datos MySQL, AWS DMS es casi siempre 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 MySQL-compatible base de datos como fuente para AWS DMS

Antes de empezar a trabajar con una base de datos MySQL como fuente de AWS DMS, asegúrese de cumplir los siguientes requisitos previos. Estos requisitos previos se aplican tanto a las fuentes autogestionadas como a las administradas. AWS

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. Es decir, las tareas de solo carga completa no necesitan este privilegio.

    nota

    Para la versión 10.5.2+ de MariaDB, puede usar BINLOG MONITOR, que reemplaza a REPLICATION CLIENT.

  • REPLICATION SLAVE: este privilegio es necesario solo para tareas de CDC. Es decir, las tareas de solo carga completa no necesitan 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 MySQL-specific previas a la migración:

grant select on mysql.user to <dms_user>;
grant select on mysql.db to <dms_user>;
grant select on mysql.tables_priv to <dms_user>;
grant select on mysql.role_edges to <dms_user>  #only for MySQL version 8.0.11 and higher
grant select on performance_schema.replication_connection_status to <dms_user>;  #Required for primary instance validation - MySQL version 5.7 and higher only

Si utiliza una fuente de RDS y tiene previsto realizar evaluaciones MySQL-specific previas a la migración, añada el siguiente permiso:

grant select on mysql.rds_configuration to <dms_user>;  #Required for binary log retention check

Si el parámetro BatchEnable es true es obligatorio conceder:

grant create temporary tables on `<schema>`.* to <dms_user>;

Utilizar una MySQL-compatible base de datos autogestionada como fuente para AWS DMS

Puede utilizar las siguientes MySQL-compatible bases de datos autogestionadas como fuentes 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

o

binlog_expire_logs_seconds

El parámetro expire_logs_days está obsoleto desde MySQL 8.0 y se ha eliminado en MySQL 8.4. Para obtener más información, consulte Variables y opciones de servidor y estado agregadas, obsoletas o eliminadas en MySQL 8.4 desde la versión 8.0.

Utilice el expire_logs_days parámetro para MySQL 5.x. Le recomendamos que defina este parámetro en un valor 1 o superior; consulte Variables y opciones de registro binario.

Utilice el binlog_expire_logs_seconds parámetro para MySQL 8.0 y versiones posteriores. Se recomienda establecer este parámetro en un valor de 86400 segundos (1 día) o superior. Consulte Opciones y variables de registro binario.

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 un AWS-base de MySQL-compatible datos gestionada como fuente de AWS DMS

Puede usar las siguientes MySQL-compatible bases de datos AWS administradas como fuentes para: AWS DMS

  • MySQL Community Edition

  • MariaDB Community Edition

  • Edición Amazon Aurora MySQL-Compatible

Cuando utilice una MySQL-compatible base AWS de datos administrada como fuente de información 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 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 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?.

  • 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 en la Guía del usuario de Amazon RDS.

  • Asegúrese de que los registros binarios estén disponibles para. AWS DMS Dado que MySQL-compatible las bases de datos AWS administradas purgan los registros binarios lo antes posible, debe aumentar el tiempo que 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 AWS DMS impedir que se capturen correctamente todos 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 garantiza que la base de datos escriba todos los cambios posteriores en la base de datos de origen en el formato correcto, de modo que AWS DMS pueda capturarlos 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 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.

Para obtener más información sobre los cambios de seguridad de Aurora MySQL 8.4, consulte Seguridad con Amazon Aurora MySQL y Administración de contraseñas con Amazon Aurora y Secrets Manager en la guía del usuario de Amazon Aurora.

Consideraciones sobre las fuentes de Aurora MySQL 8.4

Aurora MySQL 8.4 introduce cambios de seguridad que pueden afectar a la conectividad de los terminales AWS DMS de origen. Revise lo siguiente antes de actualizar su fuente de Aurora MySQL a la versión 8.4.

Aplicación de TLS

Aurora MySQL 8.4 se establece de forma ON predeterminada, lo require_secure_transport que significa que todas las conexiones deben usar TLS. Si el punto final de AWS DMS origen se conecta a Aurora MySQL 8.4 y el modo SSL está configurado como ninguno, las conexiones se rechazarán. Si el modo SSL de su punto final está configurado en ninguno, recibirá el siguiente error:MySQL Error 3159 (HY000): Connections using insecure transport are prohibited while --require_secure_transport=ON. Configure el modo SSL del punto final en verify-ca o verify-full. Ambos modos requieren un certificado de CA. También puede require_secure_transport configurarlo OFF en el grupo de parámetros del clúster de Aurora para permitir conexiones no cifradas.

nota

Aurora MySQL 8.4 solo admite los conjuntos de cifrado GCM para TLS 1.2. Se han eliminado todos los CBC-mode cifrados. AWS DMS usa TLS 1.2 para los puntos finales de MySQL y Aurora MySQL y negociará automáticamente un cifrado de GCM compatible. Si tiene configuraciones de cifrado personalizadas, compruebe que incluyen uno de los siguientes cifrados compatibles:,, o. ECDHE-RSA-AES128-GCM-SHA256 ECDHE-RSA-AES256-GCM-SHA384 ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-ECDSA-AES256-GCM-SHA384

nota

AWS DMS no admite TLS 1.3 para puntos finales de MySQL. Esto no afecta a la conectividad con Aurora MySQL 8.4, ya que Aurora MySQL 8.4 sigue siendo compatible con TLS 1.2.

Autenticación (Aurora MySQL y RDS para MySQL 8.4)

Aurora MySQL 8.4 reemplaza el default_authentication_plugin parámetro porauthentication_policy, cuyo valor predeterminado es. *:caching_sha2_password Los usuarios de bases de datos existentes conservan su complemento de autenticación actual tras la actualización. Si crea nuevos usuarios de AWS DMS punto final después de la actualización, lo usarán de forma caching_sha2_password predeterminada, a menos que lo establezca authentication_policy *:mysql_native_password en el grupo de parámetros del clúster.

Restablecimiento de la contraseña del usuario maestro

Tras actualizar a Aurora MySQL 8.4, al restablecer la contraseña del usuario maestro mediante la CLI o mediante la Consola de administración de AWS rotación de Secrets Manager, el complemento de autenticación del usuario maestro se establece en el valor predeterminado definido por el authentication_policy parámetro. Si authentication_policy se establece en su valor predeterminado (*:caching_sha2_password), el complemento de autenticación del usuario maestro cambiará de mysql_native_password a la la siguiente caching_sha2_password vez que se restablezca la contraseña.

Si el punto final de AWS DMS origen usa la cuenta de usuario maestra, verifica la conectividad después de restablecer la contraseña. Para evitar cambios en el complemento de autenticación, puedes hacer lo siguiente:

  • authentication_policy*:mysql_native_passwordConfigúralo en el grupo de parámetros de tu clúster antes de restablecer la contraseña, o

  • Crea un usuario de AWS DMS punto final dedicado con un complemento de autenticación especificado de forma explícita (recomendado). Por ejemplo: CREATE USER 'dms_user'@'%' IDENTIFIED WITH mysql_native_password BY 'password';

Limitaciones en el 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 código fuente, al configurar el modo de preparación de tablas de destino en Eliminar tablas en el destino, se 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 a la mitad de una tabla (AFTER). Las columnas siempre se añaden al final de la tabla. Cuando el objetivo es Amazon S3 o Amazon Kinesis Data Streams, se permite agregar columnas con 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+.

  • Puede usar Aurora MySQL-Compatible Edition Serverless v1 para 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.

    Aurora MySQL-Compatible Edition Serverless v2 es compatible con los CDC.

  • El atributo AUTO_INCREMENT 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.

  • No puede usar réplicas de Aurora MySQL como fuente a AWS DMS menos que el modo de tarea de migración de DMS sea Migrar los datos existentes (solo a carga completa).

  • Si la MySQL-compatible fuente se detiene durante la carga completa, la AWS DMS tarea 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_ten_chars ON customer (name(10)) no se crea en el destino.

  • En algunos casos, la tarea está configurada para no replicar los LOB (SupportLobs«" es falso en la configuración de la tarea o se elige No incluir las columnas de LOB en la consola de tareas). En estos casos, AWS DMS no migra ninguna columna de MEDIUMBLOB, LONGBLOB, MEDIUMTEXT y 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 se migra entre dos clústeres de Aurora MySQL de Amazon RDS, el punto final de origen de Aurora MySQL de RDS debe ser una instancia, no una instancia de réplica. read/write

  • AWS DMS actualmente no admite la migración de vistas para MariaDB.

  • AWS DMS no admite cambios de DDL en 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 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 a continuación. Compatibilidad con transacciones XA

  • AWS DMS no usa los GTID para la replicación, incluso si los datos de origen los contienen.

  • AWS DMS no admite 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.

  • AWS DMS no captura los cambios en las columnas calculadas (VIRTUALyGENERATED ALWAYS). Para evitar esta limitación, haga lo siguiente:

    • Pre-create la tabla de destino en la base de datos de destino y crea la AWS DMS tarea con la configuración de tarea DO_NOTHING o TRUNCATE_BEFORE_LOAD carga completa.

    • 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.

  • Debido a la limitación interna de MySQL, AWS DMS puede procesar BinLogs de un tamaño no superior a 4 GB. Los BINLOG de más de 4 GB pueden generar errores en las tareas de DMS u otros comportamientos impredecibles. Debe reducir el tamaño de las transacciones para evitar que los BINLOG superen los 4 GB.

  • AWS DMS no admite comillas simples (`) ni comillas invertidas (') 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 su base de datos no usa transacciones XA, puede ignorar este permiso y la configuración IgnoreOpenXaTransactionsCheck utilizando el valor predeterminadoTRUE. 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 la versión 10.6 o superior de MariaDB Source DB.

Configuración de punto final cuando se usa 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. La configuración se especifica al crear el punto final de origen mediante la AWS DMS consola o mediante el create-endpoint comando de AWS CLI, 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.

Name Description (Descripción)

ConnectionTimeout

Utilice este atributo de conexión adicional (ECA) para establecer el tiempo de espera de conexión del punto de conexión para la instancia de MySQL, en segundos. El valor de predeterminado es de 10 segundos. Ejemplo de ECA:ConnectionTimeout=30.
EventsPollInterval

Especifica la frecuencia con la que se debe comprobar si el registro binario es nuevo changes/events cuando la base de datos está inactiva.

Valor predeterminado: 5

Valores válidos: 1-60

Ejemplo: --my-sql-settings '{"EventsPollInterval": 5}'

En el ejemplo, AWS DMS comprueba los cambios en los registros binarios cada cinco segundos.
ExecuteTimeout

Para AWS DMS las versiones 3.4.7 y superiores, establece el tiempo de espera de la sentencia del cliente para un punto final de origen de MySQL, en segundos.

Valor predeterminado: 60

Ejemplo: --my-sql-settings '{"ExecuteTimeout": 1500}'
ServerTimezone

Especifica la zona horaria para el origen de la base de datos MySQL.

Ejemplo: --my-sql-settings '{"ServerTimezone": "US/Pacific"}'
AfterConnectScript

Especifica un script que se ejecutará inmediatamente después de AWS DMS conectarse al punto final. La tarea de migración continúa ejecutándose independientemente de si la instrucción SQL se realiza correcta o incorrectamente.

Valores válidos: una o varias instrucciones SQL válidas separadas mediante punto y coma.

Ejemplo: --my-sql-settings '{"AfterConnectScript": "ALTER SESSION SET CURRENT_SCHEMA=system"}'
CleanSourceMetadataOnMismatch

Limpia y vuelve a crear la información de metadatos de la tabla en la instancia de replicación cuando se produce una discordancia. Por ejemplo, en una situación en la que se ejecuta una DDL modificada en la tabla podría dar como resultado información distinta sobre la tabla en caché en la instancia de replicación. Booleano.

Valor predeterminado: false

Ejemplo: --my-sql-settings '{"CleanSourceMetadataOnMismatch": false}'
skipTableSuspensionForPartitionDdl

AWS DMS no admite los cambios de DDL en las tablas particionadas de MySQL. En AWS DMS las versiones 3.4.6 y posteriores, si se establece esta opción para true omitir la suspensión de la tabla por cambios en el DDL de la partición durante la CDC. AWS DMS ignora el DDL relacionado con la tabla particionada y continúa procesando los cambios adicionales en el registro binario.

Valor predeterminado: false

Ejemplo: --my-sql-settings '{"skipTableSuspensionForPartitionDdl": true}'
IgnoreOpenXaTransactionsCheck

En las AWS DMS versiones 3.5.0 y posteriores, especifica si las tareas deben ignorar las transacciones XA abiertas al iniciarse. Configúrelo en false si el origen tiene transacciones XA.

Valor predeterminado: true

Ejemplo: --my-sql-settings '{"IgnoreOpenXaTransactionsCheck": false}'

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 a partir de los tipos de AWS DMS 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, consulteTipos de datos de AWS Database Migration Service.

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.

El rango FLOAT admitido es de -1,79E+308 a -2,23E-308, 0 y de 2,23 a 1,79 E+308 E-308

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

Esta length es la longitud del valor más largo de la ENUMERACIÓN.

SET

CADENA () length

Esta 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.