ApsaraDB RDS:Migrate data between ApsaraDB RDS for MySQL instances

Límite

Solución alternativa

El servidor que aloja la base de datos de origen debe contar con suficiente ancho de banda de salida. Un ancho de banda insuficiente reduce la velocidad de migración.

Programe la migración fuera de las horas pico y habilite el control de flujo en la configuración avanzada.

Las tablas que se van a migrar deben tener restricciones PRIMARY KEY o UNIQUE con todos los campos únicos. Sin estas restricciones, el destino podría contener registros duplicados.

Agregue una clave primaria o una restricción única a la tabla antes de iniciar la migración.

Si selecciona tablas como objetos de migración y necesita cambiarles el nombre a las tablas o columnas en el destino, una sola tarea admite hasta 1,000 tablas.

Para más de 1,000 tablas, configure varias tareas o migre la base de datos completa.

Para la migración incremental de datos: el registro binario debe estar habilitado, binlog_format debe establecerse en row y binlog_row_image debe establecerse en full. Si no se cumplen estas condiciones, la comprobación previa fallará.

Habilite el registro binario y configure los parámetros requeridos antes de iniciar la tarea. Para una base de datos MySQL autogestionada en un clúster de doble primario, establezca también log_slave_updates en ON.

Para la migración incremental de datos: los registros binarios deben conservarse durante al menos 7 días. Un periodo de retención menor puede impedir que DTS obtenga los registros, lo que provocaría inconsistencia o pérdida de datos, y el SLA de DTS podría no garantizarse.

Extienda el periodo de retención de los registros binarios a un mínimo de 7 días antes de iniciar la migración.

Durante la migración de esquemas y la migración completa de datos, no ejecute sentencias DDL para modificar los esquemas de la base de datos o de las tablas. Hacerlo causará el fallo de la tarea.

Planifique y complete todos los cambios de esquema antes de iniciar la tarea de migración.

Si solo ejecuta la migración completa de datos (sin migración incremental), no escriba datos en el origen durante la migración.

Seleccione conjuntamente la migración de esquemas, la migración completa de datos y la migración incremental de datos para mantener la consistencia de los datos.

Los cambios de datos provenientes de operaciones de registros binarios (como datos restaurados desde una copia de seguridad física u operaciones en cascada) no se registran y no se migrarán mientras la instancia esté en ejecución.

Ejecute nuevamente una migración completa de datos después de que finalice la ejecución de la instancia, si su negocio lo permite.

Para MySQL 8.0.23 o posterior: las columnas invisibles provocan pérdida de datos porque DTS no puede obtener dicha información.

Ejecute ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE; para hacer visibles las columnas antes de la migración. Consulte Invisible Columns. Las tablas sin claves primarias generan automáticamente claves primarias invisibles; hágales visibles también. Consulte Generated Invisible Primary Keys.

Límite

Solución alternativa

Las versiones de las bases de datos MySQL de origen y de destino deben ser iguales.

Verifique la compatibilidad de versiones antes de iniciar la migración.

DTS no migra datos donde se utiliza un analizador sintáctico definido mediante comentarios.

Elimine los analizadores basados en comentarios antes de la migración.

Para bases de datos de destino con MySQL 8.0.23 o posterior: las columnas invisibles en el destino provocan el fallo de la tarea y pérdida de datos.

Ejecute ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE; en el destino antes de iniciar la tarea.

Si no utiliza la migración de esquemas de DTS, asegure manualmente la compatibilidad de los tipos de campo. Por ejemplo, si un campo de origen es text pero el campo de destino es varchar(255), los datos podrían truncarse.

Utilice la migración de esquemas de DTS, o verifique y alinee manualmente los tipos de campo en el destino antes de la migración.

Si los datos de migración incluyen caracteres de 4 bytes (caracteres poco comunes o emojis), la base de datos y las tablas de destino deben usar el conjunto de caracteres UTF8mb4.

Si utiliza la migración de esquemas de DTS, establezca character_set_server en el destino como UTF8mb4. Si no usa la migración de esquemas, configure el conjunto de caracteres manualmente antes de la migración.

La migración completa de datos consume recursos de lectura y escritura tanto en el origen como en el destino, lo que puede aumentar la carga del servidor.

Programe la migración fuera de las horas pico y habilite el control de flujo en la configuración avanzada.

Durante la migración completa de datos, las operaciones INSERT simultáneas causan fragmentación de tablas en el destino. Después de la migración, el espacio de tablas del destino será mayor que el del origen.

Ejecute OPTIMIZE TABLE en el destino después de la migración si el tamaño del espacio de tablas es una preocupación.

Para columnas FLOAT o DOUBLE: DTS utiliza ROUND(COLUMN,PRECISION). Si no se especifica precisión, DTS usa 38 dígitos para FLOAT y 308 dígitos para DOUBLE de forma predeterminada.

Verifique que los valores de precisión predeterminados cumplan con sus requisitos antes de iniciar la tarea.

DTS intenta reanudar las tareas fallidas durante un máximo de 7 días. Si no se detienen antes de cambiar las cargas de trabajo, una tarea reanudada podría sobrescribir los datos del destino con los datos del origen.

Detenga o libere cualquier tarea fallida antes de cambiar las cargas de trabajo al destino. Alternativamente, ejecute REVOKE para revocar los permisos de escritura de las cuentas de DTS en el destino.

Si las sentencias DDL fallan al ejecutarse en el destino, la tarea de DTS continúa.

Consulte las sentencias DDL fallidas en los registros de la tarea. Véase View task logs.

Si los nombres de columna dentro de la misma tabla MySQL de destino difieren solo en mayúsculas y minúsculas, los resultados podrían ser inesperados, ya que los nombres de columna en MySQL no distinguen entre mayúsculas y minúsculas.

Normalice el uso de mayúsculas y minúsculas en los nombres de columna del destino antes de la migración.

Una vez completada la migración (el Status de la instancia cambia a Completed), los datos escritos durante un cambio por alta disponibilidad (HA) podrían existir solo en memoria, lo que causaría pérdida de datos.

Ejecute analyze table <table name> en el destino después de la migración para verificar que los datos se escribieron correctamente.

Las instancias de RDS MySQL con EncDB habilitado no admiten la migración completa de datos.

Deshabilite EncDB o utilice un método de migración diferente. Nota: Las instancias de RDS MySQL con TDE habilitado sí admiten la migración de esquemas, la migración completa de datos y la migración incremental de datos.

Si una tarea de DTS falla, el soporte técnico de DTS intentará restaurarla en un plazo de 8 horas. Durante la restauración, la tarea podría reiniciarse y se podrían modificar los parámetros de la tarea (no los parámetros de la base de datos).

No se requiere ninguna acción; esto lo gestiona el soporte de DTS.

Escenario

Límite

Solución alternativa

Origen MySQL autogestionado

Un cambio de primario/secundario mientras la tarea está en ejecución provoca el fallo de la tarea.

Evite los cambios durante la migración.

Origen MySQL autogestionado

DTS ejecuta CREATE DATABASE IF NOT EXISTS \ test\`` en el origen de forma programada para avanzar la posición del registro binario. Si no se ejecutan operaciones DML en el origen durante un periodo prolongado, las lecturas de latencia de la migración podrían ser inexactas.

Ejecute una operación DML en el origen para actualizar el valor de latencia. Si migra una base de datos completa, cree una tabla de latidos que reciba datos cada segundo.

Origen ApsaraDB RDS for MySQL

Una instancia de solo lectura de ApsaraDB RDS for MySQL V5.6 que no registra transacciones no puede usarse como origen para la migración incremental de datos.

Utilice una instancia de origen diferente u otro tipo de migración.

Origen ApsaraDB RDS for MySQL

DTS ejecuta CREATE DATABASE IF NOT EXISTS \ test\`` en la base de datos de origen según lo programado para avanzar la posición del archivo de registro binario.

No se requiere ninguna acción; DTS lo gestiona automáticamente.

Destino ApsaraDB RDS for MySQL

DTS crea automáticamente la base de datos de destino. Sin embargo, si el nombre de la base de datos de origen no cumple con las convenciones de nomenclatura de ApsaraDB RDS for MySQL, la creación automática fallará.

Cree manualmente la base de datos en la instancia de destino antes de configurar la tarea de migración. Consulte Manage databases.