Data Transmission Service:Migrar datos de RDS MySQL a una base de datos Doris autogestionada

Permisos obligatorios

Para crear cuentas y otorgar permisos:

• RDS for MySQL: consulte Create an account y Modify the permissions of an account.

• Doris: consulte Autenticación y autorización.

Requisitos del registro binario (solo para migración incremental)

Para la migración incremental, la instancia de RDS for MySQL de origen debe tener el registro binario configurado correctamente:

• binlog_format = ROW

• binlog_row_image = FULL

• Retención local del registro binario: como mínimo 3 días (se recomiendan 7 días)

Si el origen es una base de datos MySQL autogestionada, los registros binarios locales deben conservarse durante al menos 7 días.

Si alguna de estas configuraciones es incorrecta, la comprobación previa falla y la migración no puede iniciarse.

Para obtener instrucciones sobre cómo establecer el periodo de retención del registro binario en RDS for MySQL, consulte Delete local logs automatically .

Límites de la base de datos de origen

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

• Si ejecuta una migración incremental en un clúster MySQL autogestionado con doble nodo primario (donde cada nodo actúa como primario del otro), habilite el parámetro log_slave_updates en el origen.

• Para migrar tablas con ediciones a nivel de columna (como la asignación de nombres de columnas), una sola tarea admite un máximo de 1,000 tablas. En migraciones más grandes, divida las tablas en varias tareas o migre toda la base de datos.

• No ejecute operaciones DDL que modifiquen el esquema de la base de datos o de las tablas durante la migración de esquemas ni durante la migración completa de datos, ya que esto provocará errores en la tarea.

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

• Los datos generados por operaciones que no se registran en los registros binarios, como la restauración de copias de seguridad físicas o las operaciones en cascada, no se migran.

• Si el origen es MySQL 8.0.23 o posterior y los datos contienen columnas invisibles, dichas columnas no se migran, lo que podría causar pérdida de datos. Ejecute ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE; para hacer visibles las columnas invisibles antes de la migración. Las tablas sin clave primaria generan automáticamente una clave primaria invisible, por lo que también debe hacerla visible. Para obtener más información, consulte Generated Invisible Primary Keys.

• Las instancias de RDS for MySQL con la función always-confidential habilitada no admiten la migración completa de datos. Las instancias con Transparent Data Encryption (TDE) habilitado admiten todos los tipos de migración.

Límites del destino (Doris)

• DTS solo puede escribir en tablas que utilizan el modelo Unique Key o Duplicate Key en Doris.

• Cuando una tabla de destino usa el modelo Duplicate Key, DTS convierte las instrucciones UPDATE y DELETE en instrucciones INSERT. Pueden aparecer filas duplicadas si la tarea de migración se reintenta o se reinicia, o si varias operaciones DML afectan el mismo registro entre sincronizaciones. Utilice las columnas adicionales _is_deleted, _version y _record_id para eliminar duplicados. Consulte Additional column information para obtener más detalles.

• El único parámetro de tabla configurable en DTS es bucket_count (número de buckets). El valor debe ser un número entero positivo; el valor predeterminado es auto.

• No cree un clúster nuevo en la base de datos Doris de destino durante la migración. Si la tarea falla por este motivo, reinicie la instancia de migración.

• No agregue nodos de backend (BE) al clúster de Doris durante la migración. Si la tarea falla por este motivo, reinicie la instancia de migración.

• Doris solo acepta nombres de bases de datos y tablas que comienzan con una letra. Utilice la asignación de nombres de objetos para renombrar cualquier objeto que no cumpla con esta regla.

• Si algún nombre de base de datos, tabla o columna contiene caracteres chinos, utilice la asignación de nombres de objetos para cambiarlo (por ejemplo, a un nombre en inglés). De lo contrario, la tarea podría fallar.

• Evite las operaciones DDL que modifican varias columnas simultáneamente o que alteran la misma tabla en intervalos muy cortos.

• En escenarios de fusión de varias tablas (donde múltiples tablas de origen se combinan en una sola tabla de destino), las tablas de origen deben tener esquemas idénticos.

• MySQL VARCHAR(M) utiliza longitud de caracteres (M), mientras que Doris VARCHAR(N) emplea longitud de bytes (N). Si omite la migración de esquemas y crea las tablas de Doris manualmente, establezca la longitud VARCHAR de Doris en cuatro veces la longitud VARCHAR de MySQL.

• Al usar Data Management (DMS) o gh-ost para ejecutar DDL en línea en el origen, DTS migra únicamente las instrucciones DDL originales y no los datos de las tablas temporales. Esto podría provocar bloqueos de tablas en el destino. pt-online-schema-change no es compatible con DDL en línea en el origen; su uso puede causar pérdida de datos o fallos en la tarea.

• No utilice herramientas como pt-online-schema-change en los objetos de migración de la base de datos de origen durante el proceso.

• La migración completa de datos utiliza operaciones INSERT concurrentes, lo que genera fragmentación en las tablas. Después de este proceso, las tablas de destino podrían ocupar más almacenamiento que las de origen.

• Si otra fuente escribe en la base de datos de destino durante la migración, podrían producirse inconsistencias en los datos.

Comportamiento de la migración incremental

De forma predeterminada, DTS procesa por lotes las escrituras incrementales en el destino como máximo una vez cada 5 segundos por objeto de sincronización. Esto genera una latencia de sincronización normal de hasta 10 segundos.

Para reducir la latencia, ajuste el parámetro selectdb.reservoir.timeout.milliseconds de la instancia de DTS en la consola. El rango válido es de 1,000 a 10,000 milisegundos.

Los intervalos de procesamiento por lotes más cortos aumentan la frecuencia de escritura en el destino. Esto incrementa la carga y el tiempo de respuesta (RT) en Doris, lo que podría elevar la latencia general de sincronización. Ajústelos según la capacidad de carga del destino.

Recomendaciones de rendimiento

Antes de iniciar la migración, compruebe que la carga de CPU de las bases de datos de origen y de destino sea inferior al 30 %. Ejecute la migración fuera del horario de mayor actividad para minimizar el impacto en las cargas de trabajo de producción.

Casos especiales

Si el origen es una base de datos MySQL autogestionada:

• Un failover entre nodos primario y secundario en el origen provoca errores en la tarea de migración.

• DTS calcula la latencia comparando la marca de tiempo UNIX del último registro migrado con la hora actual. Si no se ejecutan operaciones DML en el origen durante un periodo prolongado, la latencia mostrada podría ser inexacta. Ejecute una operación DML en el origen para actualizarla o cree una tabla de latidos (heartbeat) en la que se escriba cada segundo.

• DTS ejecuta periódicamente CREATE DATABASE IF NOT EXISTS en el origen para avanzar el desplazamiento del registro binario.

• Para Amazon Aurora MySQL u otras instancias MySQL en clúster, confirme que el nombre de dominio o la dirección IP configurados en la tarea siempre resuelvan al nodo de lectura y escritura (RW).

Si el origen es una instancia de RDS for MySQL:

• Las instancias de solo lectura de RDS for MySQL (como las de RDS for MySQL 5.6) no registran registros de transacciones, por lo que no pueden utilizarse como origen para la migración incremental.

• DTS ejecuta periódicamente CREATE DATABASE IF NOT EXISTS en el origen para avanzar el desplazamiento del registro binario.

Paso 1: Abrir la página Data Migration

Utilice uno de los siguientes métodos para abrir la página Data Migration.

Consola de DTS

1. Inicie sesión en la consola de DTS.

2. En el panel de navegación izquierdo, haga clic en Data Migration.

3. En la esquina superior izquierda, seleccione la región donde reside la instancia de migración.

Consola de Data Management (DMS)

La ruta de navegación exacta puede variar según el modo y el diseño de la consola de DMS. Para obtener más detalles, consulte Simple mode y Customize the layout and style of the DMS console .

1. Inicie sesión en la consola de DMS.

2. En la barra de navegación superior, coloque el puntero sobre Data + AI > DTS (DTS) > Data Migration.

3. En la lista desplegable junto a Data Migration Tasks, seleccione la región.

Paso 2: Configurar las bases de datos de origen y de destino

Haga clic en Create Task para abrir la página de configuración de la tarea y configure los siguientes parámetros.

Paso 3: Probar la conectividad

En la parte inferior de la página, haga clic en Test Connectivity and Proceed. En el cuadro de diálogo CIDR Blocks of DTS Servers, haga clic en Confirm authorization and test link.

Asegúrese de que los bloques CIDR del servidor de DTS puedan agregarse (de forma automática o manual) a la configuración de seguridad tanto del origen como del destino. Para obtener más detalles, consulte Add DTS server IP addresses to a whitelist.

Paso 4: Seleccionar los objetos y tipos de migración

En la página Configure Objects, configure los siguientes ajustes.

Tipos de migración

Modo de procesamiento de tablas en conflicto

Uso de mayúsculas en los nombres de objetos de la instancia de destino

De forma predeterminada, se aplica DTS default policy. Modifique esta opción si necesita que el uso de mayúsculas en los nombres de objetos coincida con el del origen o el destino. Consulte Specify the capitalization of object names in the destination instance.

Selección y configuración de objetos de migración

1. En Source Objects, seleccione las bases de datos o tablas que desea migrar y luego haga clic en para moverlas a Selected Objects.

2. En Selected Objects, haga clic con el botón derecho en cualquier objeto para:

   • Asignarle un nombre distinto en el destino

   • Seleccionar operaciones SQL incrementales específicas a nivel de base de datos o de tabla

   • Establecer condiciones WHERE para filtrar filas (Set filter conditions)

   • Configurar el parámetro bucket_count (si seleccionó la migración de esquemas): haga clic con el botón derecho en una tabla, vaya a Parameter Settings, establezca Enable Parameter Settings en Yes, introduzca el valor y haga clic en OK

El uso de la asignación de nombres de objetos puede provocar que los objetos dependientes fallen durante la migración.

Paso 5: Configurar los ajustes avanzados

Haga clic en Next: Advanced Settings y configure los siguientes parámetros.

Paso 6: (Opcional) Configurar los campos de bases de datos y tablas

Haga clic en Next: Configure Database and Table Fields para establecer Primary Key Column, Distribution Key y Engine de las tablas de destino.

Este paso está disponible solo si se selecciona Schema Migration .

Establezca Definition Status en All para ver y modificar todas las tablas.

Primary Key Column admite claves primarias compuestas. Seleccione una o más columnas de Primary Key Column como Distribution Key .

Para las tablas sin clave primaria ni restricción UNIQUE, establezca Engine en duplicate .

Paso 7: Ejecutar la comprobación previa

Haga clic en Next: Save Task Settings and Precheck.

Para previsualizar los parámetros de openapi antes de guardar, coloque el cursor sobre Next: Save Task Settings and Precheck y haga clic en Preview OpenAPI parameters.

DTS ejecuta una comprobación previa antes de iniciar la migración. La tarea comienza únicamente cuando esta comprobación se supera correctamente.

• Si algún elemento falla, haga clic en View Details junto al elemento con errores, resuelva el problema y haga clic en Precheck Again.

• Si aparece una alerta no crítica que pueda ignorarse de forma segura, haga clic en Confirm Alert Details > Ignore > OK > Precheck Again. Ignorar alertas puede generar inconsistencias en los datos.

Paso 8: Adquirir e iniciar la instancia

1. Espere hasta que Success Rate alcance el 100% y luego haga clic en Next: Purchase Instance.

2. En la página Purchase Instance, configure la instancia:

   Parámetro	Descripción
   Resource Group	Resource group para la instancia de migración (valor predeterminado: default resource group). Consulte What is Resource Management?
   Instance Class	Determina la velocidad de migración. Elija la opción adecuada según sus requisitos. Consulte Instance classes of data migration instances.

3. Lea y acepte los Data Transmission Service (Pay-as-you-go) Service Terms.

4. Haga clic en Buy and Start y luego en OK en el cuadro de diálogo de confirmación.

Verificar el estado de la migración

Consulte el progreso de la tarea en la página Data Migration.

• Solo migración completa: la tarea se detiene automáticamente al finalizar. El estado muestra Completed.

• Migración completa e incremental: la fase incremental se ejecuta de forma continua. El estado muestra Running.

Si una instancia presenta errores, el equipo de soporte de DTS intenta recuperarla en un plazo de 8 horas. Las operaciones de recuperación pueden incluir reiniciar la instancia y ajustar los parámetros de la instancia de DTS (no los de la base de datos). Para obtener más detalles, consulte Modify instance parameters .