View a markdown version of this page

Uso de una MySQL-compatible base de datos como destino para AWS Database Migration Service - AWS Database Migration Service
Requisitos previos de MySQL como destinoObjetivos de Aurora MySQL 8.4Restricciones a MySQL como destinoConfiguración del punto de conexiónTipos de datos de destino 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.

Uso de una MySQL-compatible base de datos como destino para AWS Database Migration Service

Puede migrar datos a cualquier MySQL-compatible base de datos utilizando AWS DMS cualquiera de los motores de datos de origen AWS DMS compatibles. Si va a migrar a una MySQL-compatible base de datos local, es AWS DMS necesario que el motor de origen resida en el AWS ecosistema. El motor puede estar en un servicio AWS gestionado, como Amazon RDS, Amazon Aurora o Amazon S3. O el motor puede estar en una base de datos autoadministrada en Amazon EC2.

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.

Para obtener información sobre las versiones de MySQL AWS DMS compatibles como destino, consulteObjetivos para AWS DMS.

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

  • Amazon Aurora MySQL

nota

Independientemente del motor de almacenamiento de origen (MyISAM, MEMORY, etc.) AWS DMS , crea MySQL-compatible una tabla de destino como tabla de InnoDB de forma predeterminada.

Si necesita una tabla en un motor de almacenamiento que no sea InnoDB, puede crear manualmente la tabla en el MySQL-compatible destino y migrarla mediante la opción No hacer nada. Para obtener más información, consulte Full-load configuración de tareas.

Para obtener información adicional sobre cómo trabajar con una MySQL-compatible base de datos como destino AWS DMS, consulte las siguientes secciones.

Utilizar cualquier MySQL-compatible base de datos como destino para AWS Database Migration Service

Antes de empezar a trabajar con una MySQL-compatible base de datos como destino AWS DMS, asegúrese de haber cumplido los siguientes requisitos previos:

  • Proporcione una cuenta de usuario AWS DMS que tenga read/write privilegios en la MySQL-compatible base de datos. Para crear los privilegios necesarios, ejecute los siguientes comandos.

    
CREATE USER '<user acct>'@'%' IDENTIFIED BY '<user password>';
GRANT ALTER, CREATE, DROP, INDEX, INSERT, UPDATE, DELETE, SELECT, CREATE TEMPORARY TABLES  ON <schema>.* TO 
'<user acct>'@'%';
GRANT ALL PRIVILEGES ON awsdms_control.* TO '<user acct>'@'%';

  • Durante la fase de migración de carga completa, debe desactivar las claves externas en las tablas de destino. Para deshabilitar las comprobaciones de claves externas en una MySQL-compatible base de datos durante una carga completa, puede añadir el siguiente comando a la sección de atributos de conexión adicionales de la AWS DMS consola del terminal de destino.

    Initstmt=SET FOREIGN_KEY_CHECKS=0;

  • Establezca el parámetro de base de datos local_infile = 1 para permitir que AWS DMS cargue datos en la base de datos de destino.

  • Otorgue los siguientes privilegios si utiliza las 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

Consideraciones sobre los objetivos de Aurora MySQL 8.4

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

Aplicación de TLS

Aurora MySQL 8.4 está configurada require_secure_transport de forma ON predeterminada, lo que significa que todas las conexiones deben usar TLS. Si el punto final de AWS DMS destino se conecta a Aurora MySQL 8.4 y el modo SSL está establecido en ninguno, se rechazarán las conexiones. 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. Como alternativa, require_secure_transport OFF configúrelo en el grupo de parámetros del clúster de Aurora para permitir conexiones sin cifrar.

nota

Aurora MySQL 8.4 solo admite conjuntos de cifrado GCM para TLS 1.2. Se han eliminado todos los CBC-mode cifrados. AWS DMS utiliza TLS 1.2 para los puntos finales de MySQL y Aurora MySQL y negociará automáticamente un cifrado GCM compatible. Si tienes configuraciones de cifrado personalizadas, verifica que incluyan 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 es compatible con 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, se utilizarán de forma caching_sha2_password predeterminada, a menos que lo establezca authentication_policy *:mysql_native_password en el grupo de parámetros de su 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 rotación Consola de administración de AWS, CLI o Secrets Manager, se establece el complemento de autenticación del usuario maestro 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 próxima caching_sha2_password vez que se restablezca la contraseña.

Si el terminal de AWS DMS destino utiliza la cuenta de usuario maestra, compruebe la conectividad después de restablecer la contraseña. Para evitar cambios en el complemento de autenticación, haga lo siguiente:

  • authentication_policyConfigúrelo *:mysql_native_password en el grupo de parámetros de su clúster antes de restablecer la contraseña, o

  • Cree 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';

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. Para obtener información sobre los problemas conocidos del complemento de autenticación, consulte el complemento de autenticación en la Guía del usuario de Amazon RDS.

Limitaciones a la hora de utilizar una MySQL-compatible base de datos como destino para AWS Database Migration Service

Cuando se utiliza una base de datos MySQL como destino, AWS DMS no admite lo siguiente:

  • Las instrucciones del lenguaje de definición de datos (DDL): TRUNCATE PARTITION, DROP TABLE y RENAME TABLE.

  • Utilizar una instrucción ALTER TABLE table_name ADD COLUMN column_name para añadir columnas al inicio o en la mitad de una tabla.

  • Al cargar datos en un MySQL-compatible destino en una tarea de carga completa, AWS DMS no informa de los errores causados por restricciones en los registros de tareas, que pueden provocar errores clave duplicados o desajustes con el número de registros. Esto se debe a la forma en que MySQL maneja los datos locales con el comando LOAD DATA. Asegúrese de hacer lo siguiente durante la fase de carga completa:

    • Desactivar restricciones

    • Usa AWS DMS la validación para asegurarte de que los datos son coherentes.

  • Al actualizar el valor de una columna a su valor actual, las MySQL-compatible bases de datos muestran una 0 rows affected advertencia. Aunque este comportamiento no es un error desde el punto de vista técnico, es diferente de la forma en que abordan la situación otros motores de base de datos. Por ejemplo, Oracle realiza una actualización de una fila. En el MySQL-compatible caso de las bases de datos, AWS DMS genera una entrada en la tabla de control awsdms_apply_exceptions y registra la siguiente advertencia.

    
Some changes from the source database had no impact when applied to
the target database. See awsdms_apply_exceptions table for details.

  • Aurora sin servidor está disponible como destino para Amazon Aurora versión 2, compatible con MySQL versión 5.7. (Seleccione la versión 2.07.1 de Aurora MySQL para poder usar Aurora sin servidor con la compatibilidad de MySQL 5.7). Para obtener más información sobre Aurora sin servidor, consulte Uso de Aurora Serverless v2 en la Guía del usuario de Amazon Aurora.

  • AWS DMS no admite el uso de un punto final de lectura para Aurora o Amazon RDS, a menos que las instancias estén en modo grabable, es decir, que innodb_read_only los parámetros read_only y estén configurados en o. 0 OFF Para obtener más información acerca del uso de Amazon RDS y Aurora como objetivos, consulte lo siguiente:

  • Al replicar un tipo de datos TIME, una fracción del valor temporal no se replica.

  • Al replicar el tipo de datos TIME con un atributo de conexión adicional loadUsingCSV=false, el valor de tiempo se limita al rango [00:00:00, 23:59:59].

Configuración del punto final cuando se utiliza una MySQL-compatible base de datos como destino para AWS DMS

Puede utilizar la configuración del punto final para configurar la base de datos de MySQL-compatible destino de forma similar a como se utilizan atributos de conexión adicionales. Los ajustes se especifican al crear el punto final de destino mediante la AWS DMS consola o mediante el create-endpoint comando del 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 destino.

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.

TargetDbType

Especifica dónde se migran las tablas de origen en el destino, bien en una base de datos o en varias. Si especificaSPECIFIC_DATABASE, debe especificar el nombre de la base de datos, ya sea cuando utilice el AWS CLI o el Consola de administración de AWS.

Valor predeterminado: MULTIPLE_DATABASES

Valores válidos: {SPECIFIC_DATABASE, MULTIPLE_DATABASES}

Ejemplo: --my-sql-settings '{"TargetDbType": "MULTIPLE_DATABASES"}'

ParallelLoadThreads

Mejora el rendimiento al cargar datos en la base de datos de MySQL-compatible destino. Especifica cuántos subprocesos se van a utilizar para cargar los datos en la base de datos de MySQL-compatible destino. Si se configuran muchos subprocesos esto puede repercutir negativamente en el desempeño de la base de datos porque se requiere una conexión independiente para cada subproceso.

Valor predeterminado: 1

Valores válidos: 1-5

Ejemplo: --my-sql-settings '{"ParallelLoadThreads": 1}'

AfterConnectScript

Especifica un script que se ejecuta inmediatamente después de que AWS DMS se conecta al punto de conexión.

Por ejemplo, puede especificar que el MySQL-compatible destino traduzca las declaraciones recibidas al juego de caracteres latin1, que es el juego de caracteres compilado predeterminado de la base de datos. Este parámetro normalmente mejora el desempeño al convertir de clientes UTF8.

Ejemplo: --my-sql-settings '{"AfterConnectScript": "SET character_set_connection='latin1'"}'

MaxFileSize

Especifica el tamaño máximo (en KB) de cualquier archivo.csv utilizado para transferir datos a una base de datos. MySQL-compatible

Valor predeterminado: 32768 KB (32 MB)

Valores válidos: 1-1 048 576

--my-sql-settings '{"MaxFileSize": 512}'

También puede usar atributos de conexión adicionales para configurar la base de datos de MySQL-compatible destino.

En la tabla siguiente se muestran los atributos de conexión adicionales que puede utilizar con MySQL como destino.

Name Description (Descripción)

Initstmt=SET FOREIGN_KEY_CHECKS=0;

Desactiva las comprobaciones de claves externas.

Ejemplo: --extra-connection-attributes "Initstmt=SET FOREIGN_KEY_CHECKS=0;"

Initstmt=SET time_zone

Especifica la zona horaria de la MySQL-compatible base de datos de destino.

Valor predeterminado: UTC

Valores válidos: los nombres de las zonas horarias disponibles en la base de datos MySQL de destino.

Ejemplo: --extra-connection-attributes "Initstmt=SET time_zone=US/Pacific;"

Como alternativa, puede usar el parámetro AfterConnectScript del comando --my-sql-settings para desactivar las comprobaciones de claves foráneas y especificar la zona horaria de la base de datos.

Tipos de datos de destino para MySQL

La siguiente tabla muestra los tipos de datos de destino de la base de datos MySQL que se admiten cuando se utilizan AWS DMS y el mapeo predeterminado a partir de AWS DMS los tipos de datos.

Para obtener información adicional sobre AWS DMS los tipos de datos, consulteTipos de datos de AWS Database Migration Service.

AWS DMS tipos de datos

Tipos de datos de MySQL

BOOLEAN

BOOLEANO

BYTES

Si la longitud es de 1 a 65 535, utilice VARBINARY (longitud).

Si la longitud es de 65 536 a 2 147 483 647, utilice LONGLOB.

DATE

DATE

TIME

TIME

TIMESTAMP

"Si la escala es => 0 y =< 6, utilice DATETIME (escala)

Si la escala es => 7 y =< 9, utilice: VARCHAR (37)

INT1

TINYINT

INT2

SMALLINT

INT4

INTEGER

INT8

BIGINT

NUMERIC

DECIMAL (p,s)

REAL4

FLOAT

REAL8

DOUBLE PRECISION

STRING

Si la longitud es de 1 a 21 845, utilice VARCHAR (longitud).

Si la longitud es de 21 846 a 2 147 483 647, utilice LONGTEXT.

UINT1

UNSIGNED TINYINT

UINT2

UNSIGNED SMALLINT

UINT4

UNSIGNED INTEGER

UINT8

UNSIGNED BIGINT

WSTRING

Si la longitud es de 1 a 32 767, utilice VARCHAR (longitud).

Si la longitud es de 32 768 a 2 147 483 647, utilice LONGTEXT.

BLOB

Si la longitud es de 1 a 65 535, utilice BLOB.

Si la longitud es de 65 536 a 2 147 483 647, utilice LONGBLOB.

Si la longitud es 0, utilice LONGBLOB (compatibilidad completa con LOB).

NCLOB

Si la longitud es de 1 a 65 535, utilice TEXT.

Si la longitud es de 65 536 a 2 147 483 647, utilice LONGTEXT con ucs2 para CHARACTER SET.

Si la longitud es 0, utilice LONGTEXT (compatibilidad completa con LOB) con ucs2 para CHARACTER SET.

CLOB

Si la longitud es de 1 a 65 535, utilice TEXT.

Si la longitud es de 65 536 a 2 147 483 647, utilice LONGTEXT.

Si la longitud es 0, utilice LONGTEXT (compatibilidad completa con LOB).