Uso de una base de datos compatible con MySQL como origen para AWS DMS

Puede migrar datos de cualquier base de datos compatible con MySQL (MySQL, MariaDB o Amazon Aurora MySQL) mediante elAWS Database Migration Service. Versiones de MySQL 5.5, 5.6, 5.7 y 8.0. Las versiones 10.0.24 a 10.0.28, 10.1, 10.2, 10.3, 10.4 y 10.5, y también son compatibles con Amazon Aurora MySQL, son compatibles para MariaDB para uso local.

nota

La Support MySQL 8.0 como fuente está disponible enAWS DMS las versiones 3.4.0 y posteriores, excepto cuando la carga útil de la transacción está comprimida. AWS DMSactualmente no admite la replicación de CDC con MySQL 8.0 como fuente cuando el cifrado de registros binarios está activado.

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.

En las siguientes secciones, el término «autogestionado» se aplica a cualquier base de datos que esté instalada localmente o en Amazon EC2. El término «AWS-managed» 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 bases de datos compatibles con MySQL y AWS DMS, consulte las secciones siguientes.

Migración de MySQL a MySQL con AWS DMS

Para una migración heterogénea, en la que se migra desde un motor de base de datos distinto de MySQL a una base de datos de MySQL, AWS DMS es casi siempre la mejor herramienta de migración que se puede utilizar. Pero 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, las herramientas nativas pueden ser más eficaces.

Es recomendable usar las herramientas de migración de bases de datos de MySQL nativas como mysqldump si se dan las condiciones siguientes:

• Se trata de una migración homogénea, en la que se migra desde una base de datos de MySQL de origen a una base de datos de MySQL de destino.

• Se va a migrar una base de datos completa.

• Las herramientas nativas le permiten migrar sus datos con un tiempo de inactividad mínimo.

También puede importar datos desde una base de datos de MySQL o MariaDB existente en una instancia de base de datos de MySQL o MariaDB en Amazon RDS. Lo hace copiando la base de datos con mysqldump y canalizándola directamente en la instancia de base de datos MySQL o MariaDB en Amazon RDS. La utilidad de línea de comandos mysqldump suele usarse para crear backups y transferir datos de un servidor MySQL o MariaDB a otro. Se incluye con el software de cliente de MySQL y MariaDB.

Para obtener más información sobre la importación de una base de datos de MySQL a Amazon RDS for MySQL o Amazon Aurora MySQL Edition, consulte Importación de datos a una instancia de base de datos de MySQL e Importación de datos de una base de datos de MySQL o MariaDB a una instancia de base de datos MySQL o MariaDB en Amazon RDS.

Uso de cualquier base de datos compatible con MySQL como origen para AWS DMS

Antes de comenzar a trabajar con una base de datos MySQL como origen para AWS DMS, asegúrese de cumplir los siguientes requisitos previos. Estos requisitos previos se aplican a las fuentesAWS autogestionadas o gestionadas.

Debe tener una cuenta para AWS DMS que tiene el rol de administrador de replicación. El rol necesita los siguientes privilegios:

• CLIENTE DE REPLICACIÓN: este privilegio solo se requiere para las tareas de los CDC. En otras palabras, full-load-only las tareas no requieren este privilegio.

• REPLICATION SLAVE: este privilegio solo se requiere para las tareas de los CDC. En otras palabras, full-load-only las tareas no requieren este privilegio.

• SUPER: este privilegio es necesario únicamente en versiones de MySQL anteriores a la 5.6.6.

El usuario de AWS DMS también debe disponer de privilegios SELECT para las tablas de origen designadas para la replicación.

Uso de una base de datos compatible con MySQL autoadministrada como origen 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 ciertos casos, sibinlog_format se establece enSTATEMENT, puede provocar inconsistencias al replicar los datos en el destino. El motor de base de datos también escribe datos inconsistentes similares en el objetivo cuandobinlog_format está configurado enMIXED, porque el motor de base de datos cambia automáticamente al registroSTATEMENT basado, lo que puede provocar la escritura de datos inconsistentes 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.
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 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.

UsoAWS de una base de datos compatible con MySQL gestionada como fuente paraAWS DMS

Puede utilizar las siguientes bases de datosAWS gestionadas y compatibles con MySQL como fuentes paraAWS DMS:

• MySQL Community Edition

• MariaDB Community Edition

• Amazon Aurora MySQL-Compatible Edition

Cuando utilice una baseAWS de datos compatible con MySQL gestionada como fuenteAWS DMS, asegúrese de cumplir los siguientes requisitos previos para los CDC:

• Para habilitar los registros binarios para RDS para MySQL y para RDS para MariaDB, habilite las copias de seguridad automáticas a nivel de instancia. Para habilitar los registros binarios de un clúster de Aurora MySQL, cambie la variablebinlog_format en el grupo de parámetros.

  Para obtener más información sobre la configuración de copias de seguridad automáticas, consulte Trabajar con copias de seguridad automatizadas 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 for MySQL, consulte Configurar el 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 tiene pensado usar los 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 for MySQL, consulte Configurar el 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 las basesAWS de datos compatibles con MySQL administradas purgan los registros binarios lo antes posible, debe aumentar el tiempo durante el 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);
                      

• Defina el parámetro binlog_format como "ROW".

  nota

  Para MariaDB, si se cambia elbinlog_format parámetroROW para fines de replicación, los registros binarios posteriores se seguirán creando enMIXED formato. Esto puede impedir que el DMS capture los datos de cambios. Por lo tanto, cuando cambie elbinlog_format parámetro de MariaDB, reinicie o inicie y luego detenga la tarea de replicación.

• Defina el parámetro binlog_row_image como "Full".

• Defina el parámetro binlog_checksum como "NONE". Para obtener más información sobre la configuración de parámetros en Amazon RDS MySQL, consulte Trabajar 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 fuente, habilite las copias de seguridad en la réplica leída y asegúrese de que ellog_slave_updates parámetro esté configurado enTRUE.

Restricciones en el uso de una base de datos de MySQL como origen para AWS DMS

Cuando utilice una base de datos MySQL como origen, tenga en cuenta lo siguiente:

• La captura de datos de cambios (CDC) no se admite para Amazon RDS MySQL 5.5 o versiones anteriores. En el caso de Amazon RDS MySQL, debe usar la versión 5.6, 5.7 u 8.0 para habilitar la CDC. CDC es compatible con fuentes de MySQL 5.5 autogestionadas.

• Para CDC,CREATE TABLEADD COLUMN, yDROP COLUMN cambiar el tipo de datos de la columna, yrenaming a column son compatibles. Sin embargoDROP TABLERENAME TABLE, no se admiten las actualizaciones realizadas en otros atributos, como el valor predeterminado de la columna, la anulabilidad de la columna, el conjunto de caracteres, etc.

• Para tablas con particiones en el origen, cuando se establece Target table preparation mode (Modo de preparación de tabla de destino) en Drop tables on target (Borrar tablas en el destino), AWS DMS crea una tabla sencilla sin ninguna partición en el destino de MySQL. Para migrar tablas particionadas a una tabla particionada en el destino, cree previamente las tablas particionadas en la base de datos MySQL de destino.

• No se permite utilizar una instrucción ALTER TABLE table_name ADD COLUMN column_name para agregar columnas al principio (FIRST) o en medio de una tabla (AFTER). Las columnas siempre se añaden al final de la tabla.

• 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 que utilizan HFS+.

• Puede usar Aurora MySQL compatible con Serverless para la carga completa, pero no puede usarla para CDC. Esto se debe a que no puede habilitar los requisitos previos para MySQL. Para obtener más información, consulte Grupos de parámetros y Aurora Serverless v1.

• 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, los CDC no funcionan 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 utilizar réplicas de Aurora MySQL como fuente aAWS DMS menos que el 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_ten_chars ON customer (name(10)) no se crea en el destino.

• En algunos casos, la tarea está configurada para no replicar los LOB (en la configuración de la tarea se eligeSupportLobs «No incluir columnas de LOB»). En estos casos, AWS DMS no migra ninguna columna MEDIUMBLOB, LONGBLOB, MEDIUMTEXT y LONGTEXT al destino.

  Las columnas BLOB, TINYBLOB, TEXT y TINYTEXT no se ven afectadas y se migran al destino.

• Las bases de datos de origen y destino de MariaDB no admiten tablas de datos temporales ni tablas versionadas por el sistema.

• Si se migra entre dos clústeres Aurora MySQL de Amazon RDS, el extremo de origen de RDS Aurora MySQL debe ser una instancia de lectura/escritura, no una instancia de réplica.

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

• AWS DMSno admite cambios de DDL para tablas particionadas para MySQL. Para omitir la suspensión de tablas por cambios en el DDL de la partición durante la CDC,skipTableSuspensionForPartitionDdl defina entrue.

• AWS DMSno es compatible actualmente transacciones XA.

• AWS DMSno admite GTID para la replicación.

• AWS DMSno admite la compresión de transacciones de registro binario.

Configuración de endpoint cuando se usa MySQL como fuente paraAWS DMS

Puede utilizar la configuración de punto final para configurar la base de datos fuente de MySQL de forma similar a usar atributos de conexión adicionales. La configuración se especifica al crear el extremo de origen mediante laAWS DMS consola o mediante elcreate-endpoint comando de AWS CLI, con la sintaxis--my-sql-settings '{"EndpointSetting": "value", ...}' JSON.

En la tabla siguiente, se muestran las configuraciones de punto de conexión que se pueden utilizar con MySQL como fuente.

Nombre	Descripción
EventsPollInterval	Especifica la frecuencia con la que se va a consultar el registro binario para comprobar si hay cambios o eventos nuevos 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 si se han producido cambios en los registros binarios cada cinco segundos.
ExecuteTimeout	ParaAWS DMS las versiones 3.4.7 y posteriores, 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 ejecuta inmediatamente después de que AWS DMS se conecta al punto de conexión. 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"}'
CleanSrcMetadataOnMismatch	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 '{"CleanSrcMetadataOnMismatch": false}'
skipTableSuspensionForPartitionDdl	AWS DMSno admite cambios de DDL para tablas particionadas para MySQL. ParaAWS DMS las versiones 3.4.6 y posteriores, al establecer esta opción setrue omite la suspensión de la tabla por cambios en el DDL de la partición durante la CDC. AWS DMSignora el partitioned-table-related DDL y continúa procesando más cambios en el registro binario. Valor predeterminado: false Ejemplo: --my-sql-settings '{"skipTableSuspensionForPartitionDdl": true}'

Tipos de datos de origen para MySQL

En la siguiente tabla se muestran los tipos de datos de origen de la base de datos de MySQL que se admiten cuando se utiliza AWS DMS y el mapeo predeterminado de los tipos de datos de AWS DMS.

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 más información sobre los tipos de datos de AWS DMS, consulte Tipos de datos para elAWS Database Migration Service.

Tipos de datos de MySQL	Tipos de datos de AWS DMS
INT	INT4
BIGINT	INT8
MEDIUMINT	INT4
TINYINT	INT1
SMALLINT	INT2
UNSIGNED TINYINT	UINT1
UNSIGNED SMALLINT	UINT2
MEDIO SIN SIGNO	UINT4
INT SIN SIGNO	UINT4
UNSIGNED BIGINT	UINT8
DECIMAL (10)	NUMERIC (10,0)
BINARY	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. El DATETIME con un valor entre paréntesis de 1 a 5 (por ejemploDATETIME(5)) se replica en 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 de FLOAT no están en el rango siguiente, utilice 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,23E-308 a 1,79E+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	CADENA (25)
GEOMETRY	BLOB
POINT	BLOB
LINESTRING	BLOB
POLYGON	BLOB
MULTIPOINT	BLOB
MULTILINESTRING	BLOB
MULTIPOLYGON	BLOB
GEOMETRYCOLLECTION	BLOB
ENUM	STRING (longitud) Aquí, la longitud es la longitud del valor más largo de la ENUM.
SET	STRING (longitud) Aquí, la longitud 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, 0000-00-00). 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.