¿Cuáles son las prácticas recomendadas a seguir al migrar una base de datos MySQL de RDS de origen a una base de datos MySQL de RDS de destino mediante AWS DMS?

Última actualización: 19-08-2022

Tengo una base de datos MySQL que quiero migrar a una base de datos de Amazon Relational Database Service (Amazon RDS) para MySQL mediante AWS Database Migration Service (AWS DMS). ¿Qué prácticas recomendadas puedo utilizar para optimizar la migración entre una base de datos MySQL de origen y una base de datos MySQL de destino?

Descripción corta

Con AWS DMS, puede migrar datos de un almacén de datos de origen a un almacén de datos de destino. Estos dos almacenes de datos se denominan puntos de conexión. Puede migrar entre puntos de conexión de origen y destino que utilizan el mismo motor de base de datos, por ejemplo, desde una base de datos MySQL a otra base de datos MySQL.

Si bien AWS DMS crea los objetos de esquema de destino, solo crea los objetos mínimos que necesita para que los datos se migren de forma eficaz desde el origen. Por lo tanto, AWS DMS crea tablas, claves principales y, en algunos casos, índices únicos, pero no crea objetos como índices secundarios, restricciones de claves no principales y valores predeterminados de datos. Para obtener más información sobre lo que migra AWS DMS, consulte Vista general de AWS DMS.

Crear previamente las tablas en la base de datos de destino antes de la migración

Para conservar las definiciones de datos predeterminadas, cree previamente las tablas en la base de datos de destino antes de la migración. Utilice uno de estos enfoques, según el tipo de migración que esté realizando:

  • Para migraciones homogéneas, por ejemplo, de MySQL a MySQL, utilice las utilidades nativas del motor de base de datos, como mysqldump, para exportar las definiciones de las tablas. A continuación, importe estas definiciones de tabla en el destino sin los datos. Después de crear las definiciones de tabla, utilice la tarea de AWS DMS con el modo de preparación de tablas de destino establecido en TRUNCATE_BEFORE_LOAD para cargar los datos.
  • Para migraciones entre diferentes motores de bases de datos, utilice la Herramienta de conversión de esquemas de AWS (AWS SCT). También puede usar este método para bases de datos homogéneas. AWS SCT se conecta a sus bases de datos de origen y destino y, a continuación, convierte el esquema de base de datos existente de un motor de base de datos a otro. Puede usar AWS SCT para crear previamente tablas en la base de datos de destino con las definiciones de datos predeterminadas intactas. A continuación, utilice la tarea de AWS DMS con el modo de preparación de tablas de destino establecido en TRUNCATE_BEFORE_LOAD para cargar los datos. Para obtener más información, consulte Converting your schema by using AWS SCT (Convertir su esquema con AWS SCT).

Resolución

Siga las prácticas recomendadas para la migración de MySQL a MySQL de AWS DMS

Utilice estas prácticas recomendadas cuando migre datos desde una base de datos MySQL de origen a una base de datos MySQL de destino.

  • Desactive las copias de seguridad y los registros específicos de la base de datos (como bin, general y audit) en la base de datos de destino durante la migración. Si lo necesita, puede volver a activarlos para solucionar problemas.
  • Desactive los desencadenadores, otros trabajos cron y los programadores de eventos en la base de datos de destino durante la migración.
  • Evite usar Multi-AZ en la base de datos de Amazon RDS de destino al realizar la migración de AWS DMS.
  • Evite aplicar cualquier otro tráfico de clientes externos a la base de datos de destino al realizar la migración.
  • Aprovisione la instancia de replicación de AWS DMS, las bases de datos de origen y las bases de datos de destino con la CPU, la memoria, el almacenamiento y las IOPS necesarios para evitar la contención de recursos durante la migración.
  • Configure la base de datos de origen con los requisitos previos para usar la captura de datos de cambio (change data capture, CDC) de AWS DMS antes de iniciar la migración.
  • Utilice configuraciones LOB optimizadas, como LOB limitado y LOB en línea para la migración.
  • Si la base de datos de origen contiene muchas tablas con una gran carga de trabajo, divida las tablas entre varias tareas. Divida las tablas en función de su tamaño en la base de datos de origen, el patrón de tráfico de la aplicación y la presencia de columnas LOB. Si la tabla tiene muchas columnas LOB (TEXT o JSON) con un tráfico de escritura elevado en el origen, cree una tarea independiente para la tabla. La coherencia transaccional se mantiene dentro de una tarea, por lo que es importante que las tablas de tareas separadas no participen en transacciones comunes.
  • Utilice el mecanismo de carga completa en paralelo para tablas de origen pesadas a fin de reducir el tiempo de migración. Para obtener más información, consulte Using parallel load for selected tables, views, and collections (Uso de carga paralela para tablas, vistas y colecciones seleccionadas).
  • Desactive las restricciones de clave externa en la tabla de destino durante la migración a plena carga.
  • Agregue un índice secundario en la base de datos de destino antes de iniciar la fase de replicación de CDC.
  • El usuario principal de Amazon RDS no tiene privilegios para eliminar y volver a crear para las tablas de esquema predeterminadas. Por lo tanto, evite migrar tablas de esquemas o bases de datos predeterminadas desde el origen con AWS DMS.
  • Consulte la documentación sobre Using AWS DMS to migrate data from MySQL to MySQL (Uso de AWS DMS para migrar datos de MySQL a MySQL) para obtener información sobre los tipos de datos que AWS DMS puede migrar correctamente.
  • Pruebe su carga de trabajo con la solicitud de CDC transaccional predeterminada antes de usar el método de aplicación por lotes de CDC. Para obtener más información, consulte ¿Cómo puedo utilizar la función de aplicación por lotes de DMS para mejorar el rendimiento de replicación de CDC? (¿Cómo puedo utilizar la función de aplicación por lotes de DMS para mejorar el rendimiento de replicación de CDC?)
  • Pruebe la migración con los mismos datos de producción en cualquier otro entorno de base de datos de QA/DEV antes de iniciar la migración de producción. Asegúrese de usar la misma configuración de AWS DMS cuando realice la migración de producción.

Para obtener más información, consulte Improving the performance of an AWS DMS migration (Mejorar el rendimiento de una migración de AWS DMS).

1. Cree previamente la tabla DDL en las bases de datos MySQL/PostgreSQL de destino de forma manual. A continuación, cree una tarea de AWS DMS con el modo de preparación de destino establecido en DO_DOTHING”/"TRUNCATE para migrar solo los datos.

Ejecute este comando para crear un volcado sin datos de la base de datos MySQL de origen:

mysqldump -h yourhostnameorIP -u root -p --no-data --skip-triggers --single-transaction --dbname > schema.sql

Este comando descarga la estructura DDL del origen sin ningún dato.

A continuación, ejecute este comando para restaurar la estructura DDL en el destino:

mysql -u user -p -h yourhostnameorIP  database_name < schema.sql

O bien, puede permitir que AWS DMS cree las tablas en el destino mediante el modo de preparación de destino DROP AND CREATE. A continuación, vaya al paso 3 para modificar la tabla y agregar los objetos que faltan, como índices secundarios, antes de reanudar la tarea para la fase de CDC.

Nota: De forma predeterminada, AWS DMS crea la tabla en el destino solo con la clave principal o la clave única. No migra ningún otro objeto a la base de datos MySQL de destino.

2. Durante la carga completa, AWS DMS no identifica las tablas relacionales de clave externa. Carga los datos de forma aleatoria, por lo que la carga de la tabla puede fallar si la base de datos de destino tiene activada una comprobación de clave externa. Utilice este atributo de conexión adicional (extra connection attribute, ECA) en el punto de conexión de MySQL de destino para desactivar las comprobaciones de claves externas para esta sesión de AWS DMS.

initstmt=SET FOREIGN_KEY_CHECKS=0;

Para obtener más información, consulteExtra connection attributes when using a MySQL-compatible database as a target for AWS DMS (Atributos de conexión adicionales al usar una base de datos compatible con MySQL como destino para AWS DMS).

3. En la configuración de JSON, establezca stop task before applying cache changes (detener tarea antes de aplicar cambios en la caché) en true (verdadero) y stop task after applying cached changes (detener tarea después de aplicar cambios en la caché) en true (verdadero).

"FullLoadSettings": {
    "TargetTablePrepMode": "TRUNCATE_BEFORE_LOAD"
    "CreatePkAfterFullLoad": false,
    "TransactionConsistencyTimeout": 600,
    "MaxFullLoadSubTasks": 8,
    "StopTaskCachedChangesNotApplied": true,   <--- set this to true
    "StopTaskCachedChangesApplied": true,    <--- set this to true
    "CommitRate": 50000,
}

Una vez completada la carga completa y antes de aplicar los cambios en caché, la tarea se detiene. Mientras la tarea está detenida, cree índices de clave principal e índices secundarios en el destino.

A continuación, debe reanudar la tarea, ya que la tarea se detiene de nuevo después de aplicar los cambios en la caché. Tras realizar el paso anterior, verifique los datos migrados mediante la salida de validación de AWS DMS o la verificación manual antes de reanudar la tarea de nuevo para la fase de replicación de CDC. Al completar este paso, puede identificar cualquier problema y abordarlo antes de reanudar la replicación de CDC.

4.    En la configuración de carga completa de la tarea, ajuste la configuración de commitRate para acelerar la velocidad de extracción de datos del origen. El valor predeterminado es 10 000, así que ajuste esta configuración cuando vaya a migrar una gran cantidad de datos desde la tabla de origen.

CommitRate=50000

Nota: Cambiar commitRate a un valor superior podría afectar al rendimiento, así que asegúrese de supervisar y tener suficiente memoria en la instancia de replicación.

5.    Agregue este ECA en el punto de conexión de destino para especificar el tamaño máximo (en KB) de cualquier archivo .csv utilizado para transferir datos al elemento MySQL de destino. El valor predeterminado es 32 768 KB (32 MB) y los valores válidos oscilan entre 1 y 1 048 576 KB (hasta 1,1 GB).

maxFileSize=250000;

Nota: Cuando utilice una instancia de destino, como MySQL, Aurora o MariaDB, para una carga completa, utilice esta opción para permitir que AWS DMS cree un archivo .csv en segundo plano para cargar los datos en la instancia de destino. Utilice un valor entre 32 MB y 1 GB. Sin embargo, también debe tener en cuenta el valor que puede gestionar su instancia de destino. Si tiene varias tareas que cargan 1 GB de archivo.csv, esto puede provocar una sobrecarga en la instancia de destino. Asegúrese de tener una instancia con una alta potencia de computación en el destino.

6.    Utilice la configuración de LOB limitado o LOB en línea para obtener un mejor rendimiento.

Modo LOB limitado: cuando se utiliza el modo LOB limitado, se especifica el tamaño máximo de los datos de la columna LOB. Esto permite que AWS DMS asigne previamente los recursos y, a continuación, aplique LOB de forma masiva. Si el tamaño de las columnas LOB supera el tamaño que especificó en la tarea, AWS DMS trunca los datos. A continuación, AWS DMS envía advertencias al archivo de registro de AWS DMS. El uso del modo LOB limitado mejora el rendimiento; sin embargo, antes de ejecutar la tarea, debe identificar el tamaño máximo de LOB de los datos en el origen. A continuación, especifique el valor del parámetro Max LOB size (Tamaño máximo de LOB). Se recomienda asegurarse de que tiene suficiente memoria asignada a la instancia de replicación para gestionar la tarea.

Modo LOB en línea: al usar el modo LOB en línea, puede migrar LOB sin truncar los datos ni ralentizar el rendimiento de la tarea, al replicar LOB pequeños y grandes. En primer lugar, especifique un valor para el parámetro InlineLobMaxSize, que solo está disponible cuando el modo LOB completo se establece en true (verdadero). La tarea de AWS DMS transfiere los LOB pequeños en línea, lo que es más eficiente. A continuación, AWS DMS migra los LOB que son más grandes que el tamaño especificado en el modo LOB completo realizando una búsqueda desde la tabla de origen. Sin embargo, tenga en cuenta que el modo LOB en línea solo funciona durante la fase de carga completa.

Nota: Debe establecer InlineLobMaxSize cuando especifique la configuración de la tarea.

Ejecute estas consultas para comprobar el tamaño de LOB y, a continuación, ingrese el tamaño máximo de LOB.

Enumere las tablas que tienen columnas LOB:

select tab.table_name,
count(*) as columns
from information_schema.tables as tab
inner join information_schema.columns as col
on col.table_schema = tab.table_schema
and col.table_name = tab.table_name
and col.data_type in ('blob', 'mediumblob', 'longblob',
'text', 'mediumtext', 'longtext')
where tab.table_schema = 'your database name'.  <---- enter database name here
and tab.table_type = 'BASE TABLE'
group by tab.table_name
order by tab.table_name;

Compruebe el tamaño de la columna LOB:

Select (max(length (<COL_NAME>))/(1024)) as “size in KB” from <TABLE_NAME>;

Compruebe el tamaño de las columnas LOB de todas las tablas y, a continuación, ingrese el tamaño máximo en Max LOB size (K) (Tamaño máximo de LOB [K]).

El uso de la opción Max LOB size (K) (Tamaño máximo de LOB [K]) con un valor superior a 63 KB afecta al rendimiento de una carga completa configurada para ejecutarse en modo LOB limitado. Durante una carga completa, AWS DMS asigna memoria al multiplicar el valor de Max LOB size (K) (Tamaño máximo de LOB [K]) por la tasa de confirmación. A continuación, el producto se multiplica por el número de columnas LOB.

Cuando AWS DMS no puede asignar previamente esa memoria, AWS DMS comienza a consumir memoria SWAP. Esto afecta al rendimiento de una carga completa. Por lo tanto, si experimenta problemas de rendimiento al usar el modo LOB limitado, reduzca la tasa de confirmación hasta que alcance un nivel de rendimiento aceptable. O bien, considere usar el modo LOB en línea para los puntos de conexión admitidos después de comprobar primero la distribución LOB de la tabla.

Para obtener más información, consulte Setting LOB support for source databases in an AWS DMS task (Configuración de la compatibilidad de LOB para las bases de datos de origen en una tarea de AWS DMS).


¿Le resultó útil este artículo?


¿Necesita asistencia técnica o con la facturación?