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 origen para AWS DMS
Puede migrar datos desde cualquier base de datos compatible con MySQL (MySQL, MariaDB o Amazon Aurora MySQL) con AWS Database Migration Service.
Para obtener información sobre las versiones de MySQL que AWS DMS admite como origen, consulte Fuentes de AWS DMS.
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 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 bases de datos compatibles con MySQL y AWS DMS, consulte las secciones siguientes.
Temas
- Migración de MySQL a MySQL con AWS DMS
- Uso de cualquier base de datos compatible con MySQL como origen para AWS DMS
- Uso de una base de datos compatible con MySQL autoadministrada como origen para AWS DMS
- Uso de una base de datos compatible con MySQL administrada por AWS como origen para AWS DMS
- Restricciones en el uso de una base de datos de MySQL como origen para AWS DMS
- Compatibilidad con transacciones XA
- Configuración de punto de conexión cuando se utiliza MySQL como origen para AWS DMS
- Tipos de datos de origen para MySQL
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. 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.
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 orígenes autoadministrados o administrados por AWS.
Debe tener una cuenta para AWS DMS que tiene el rol 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.
-
REPLICATION SLAVE: este privilegio es necesario solo para tareas de 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 |
---|---|
|
Establezca este parámetro con un valor de 1 o superior. |
|
Establezca la ruta del archivo de registro binario, como por ejemplo |
|
Establezca este parámetro en |
|
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. |
|
Establezca este parámetro en |
|
Establezca este parámetro en |
|
Establezca este parámetro en |
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 |
---|---|
|
Establezca este parámetro en |
|
Establezca este parámetro en |
|
Establezca este parámetro en |
Uso de una base de datos compatible con MySQL administrada por AWS como origen para AWS DMS
Puede utilizar las siguientes bases de datos compatibles con MySQL administradas por AWS como orígenes para AWS DMS:
-
MySQL Community Edition
-
MariaDB Community Edition
-
Amazon Aurora MySQL-Compatible Edition
Cuando utilice una base de datos compatible con MySQL administrada por AWS como origen para AWS DMS, asegúrese de cumplir los siguientes requisitos previos para 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 las bases de datos compatibles con MySQL administradas por AWS purgan los registros binarios tan pronto como sea posible, debe aumentar el tiempo durante el cual 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 cambiabinlog_format
aROW
con fines de replicación, la base de datos puede seguir creando registros binarios posteriores con el mismo formatoMIXED
, si esas sesiones se iniciaron antes de que cambiara el valor. Esto puede impedir que AWS DMS capture correctamente todos los cambios en la base de datos de origen. Al cambiar la configuración debinlog_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 parámetrobinlog_format
aROW
garantizará que la base de datos escriba todos los cambios de la base de datos de origen posteriores con el formato correcto, de modo que AWS DMS pueda capturar esos cambios correctamente. -
Establezca el parámetro
binlog_row_image
como"Full"
. -
Establezca el
binlog_checksum
parámetro en la versión"NONE"
3.4.7 o anterior del 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 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:
-
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
yDROP COLUMN
que cambian el tipo de datos de columna yrenaming a column
. Sin embargo, no se admitenDROP 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. -
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 con particiones a una tabla particionada en el destino, cree previamente las tablas con particiones en la base de datos de MySQL de destino.
-
No se permite utilizar una instrucción
ALTER TABLE
para agregar columnas al principio (FIRST) o en medio de una tabla (AFTER). Las columnas siempre se añaden al final de la tabla.table_name
ADD COLUMNcolumn_name
-
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 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.
-
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 utilizar réplicas de Aurora MySQL como origen para AWS DMS a menos que el modo de tarea de migración de DMS sea Migrar datos existentes, solo de 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 (SupportLobs«" es falso 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 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 migra entre dos clústeres de Amazon RDS Aurora MySQL, el punto de conexión de origen de RDS Aurora MySQL debe ser una instancia de lectura o escritura, 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
entrue
. -
AWS DMS solo es compatible con transacciones XA en la versión 3.5.0 y superiores. Las versiones anteriores no son compatibles con transacciones XA. AWS DMS no es compatible con transacciones XA en la versión 10.6 de MariaDB. Para obtener más información, consulte Compatibilidad con transacciones XA a continuación.
-
AWS DMS no utiliza GTID para la replicación, aunque los datos de origen los contienen.
-
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 de 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, AWS DMS no 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 (
VIRTUAL
yGENERATED 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
oTRUNCATE_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.
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 TRUE
predeterminado. Para empezar a replicar desde un origen que tiene transacciones XA, haga lo siguiente:
Asegúrese de que el usuario de punto de conexión de AWS DMS tenga el siguiente permiso:
grant XA_RECOVER_ADMIN on *.* to 'userName'@'%';
Establezca la configuración del punto de conexión
IgnoreOpenXaTransactionsCheck
enfalse
.
nota
AWS DMS no admite transacciones XA en MariaDB Source DB versión 10.6.
Configuración de punto de conexión cuando se utiliza MySQL como origen 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. Se especifican los ajustes cuando se crea el punto de conexión de origen mediante la consola de AWS DMS o mediante el comando create-endpoint
en la AWS CLI, con la sintaxis JSON --my-sql-settings '{"
.EndpointSetting"
:
"value"
, ...
}'
La siguiente tabla muestra la configuración de punto de conexión que puede utilizar con MySQL como origen.
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: En el ejemplo, AWS DMS comprueba si se han producido cambios en los registros binarios cada cinco segundos. |
ExecuteTimeout |
Para las versiones 3.4.7 y superiores de AWS DMS, establece el tiempo de espera de la instrucción del cliente para un punto de conexión de origen de MySQL, en segundos. Valor predeterminado: 60 Ejemplo: |
ServerTimezone |
Especifica la zona horaria para el origen de la base de datos MySQL. Ejemplo: |
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: |
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: Ejemplo: |
skipTableSuspensionForPartitionDdl
|
AWS DMS no admite cambios de DDL para tablas particionadas para MySQL. En las AWS DMS versiones 3.4.6 y posteriores, si se configura esta opción, se Valor predeterminado: Ejemplo: |
IgnoreOpenXaTransactionsCheck
|
Para las versiones 3.5.0 y superiores de AWS DMS, especifica si las tareas deben ignorar las transacciones XA abiertas al iniciarse. Configúrelo en Valor predeterminado: Ejemplo: |
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 de AWS 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 |
UNSIGNED MEDIUMINT |
UINT4 |
UNSIGNED INT |
UINT4 |
UNSIGNED BIGINT |
UINT8 |
DECIMAL (10) |
NUMERIC (10,0) |
BINARY |
BYTES(1) |
BIT |
BOOLEAN |
BIT(64) |
BYTES(8) |
BLOB |
BYTES(65535) |
LONGBLOB |
BLOB |
MEDIUMBLOB |
BLOB |
TINYBLOB |
BYTES(255) |
FECHA |
FECHA |
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 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.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 |
WSTRING(255) |
GEOMETRY |
BLOB |
POINT |
BLOB |
LINESTRING |
BLOB |
POLYGON |
BLOB |
MULTIPOINT |
BLOB |
MULTILINESTRING |
BLOB |
MULTIPOLYGON |
BLOB |
GEOMETRYCOLLECTION |
BLOB |
ENUM |
WSTRING ( Aquí, la |
SET |
WSTRING ( En este caso, la |
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.