Migrate data from a TiDB database to an RDS MySQL instance - Data Transmission Service

Este tema describe cómo utilizar Data Transmission Service (DTS) para migrar datos desde una base de datos TiDB autogestionada hacia una instancia de ApsaraDB RDS for MySQL.

Elija su ruta de migración:

Ruta	Pasos	Cuándo utilizarla
Solo migración completa	Requisitos previos → Procedimiento	Migración única con una ventana de mantenimiento breve
Migración completa + incremental	Requisitos previos → Preparativos → Procedimiento	Migración sin tiempo de inactividad; mantiene la base de datos de origen activa durante el proceso

Importante

Las tablas sin clave primaria o restricción UNIQUE pueden generar registros duplicados en la base de datos de destino. Compruebe que todas las tablas a migrar cuenten con restricciones PRIMARY KEY o UNIQUE antes de empezar.

Requisitos previos

Antes de empezar, asegúrese de contar con lo siguiente:

Una instancia de ApsaraDB RDS for MySQL con espacio de almacenamiento disponible superior al tamaño total de los datos en la base de datos TiDB de origen. Para más detalles, consulte Create an ApsaraDB RDS for MySQL instance.
(Solo para migración completa + incremental) Haber completado la sección Preparations para configurar un clúster de Kafka y establecer TiDB Binlog o TiCDC para la captura de datos incrementales.

Preparativos (solo para migración incremental)

Omita esta sección si solo requiere una migración completa de datos.

DTS lee los datos incrementales de TiDB a través de una canalización basada en Kafka. DTS lee exclusivamente desde la partición 0 del tema de Kafka, por lo que el tema debe tener exactamente una partición. Antes de crear la tarea de DTS, configure esta canalización mediante uno de los siguientes métodos.

Método 1: TiDB Binlog

Despliegue el servidor de la base de datos de origen, Pump, Drainer y el clúster de Kafka en la misma red interna para minimizar la latencia de red.

Prepare un clúster de Kafka utilizando una de estas opciones:
- Clúster de Kafka autogestionado: Consulte la documentación de Apache Kafka. Establezca message.max.bytes y replica.fetch.max.bytes en el broker, así como fetch.message.max.bytes en el consumidor, con valores suficientemente grandes para manejar el volumen del registro binario de TiDB. Para detalles de configuración, consulte CONFIGURATION.
- Instancia de ApsaraMQ for Kafka: Consulte la descripción general de inicio rápido. Despliegue la instancia en la misma virtual private cloud (VPC) que el servidor de la base de datos de origen.
Cree un tema en el clúster de Kafka o en la instancia de ApsaraMQ for Kafka.

Importante
El tema debe tener exactamente una partición. DTS lee datos incrementales únicamente desde la partición cuyo ID es 0.
Despliegue Pump y Drainer. Para más detalles, consulte Despliegue de clúster de TiDB Binlog.
Edite el archivo de configuración de Drainer para apuntar a su clúster de Kafka. Para más detalles, consulte la guía del cliente consumidor de Binlog.

Compruebe que el servidor de la base de datos TiDB pueda conectarse al clúster de Kafka.
Agregue los bloques CIDR de los servidores DTS a la lista blanca de la base de datos TiDB. Para más detalles, consulte Agregar los bloques CIDR de los servidores DTS.

Método 2: TiCDC

Prepare un clúster de Kafka utilizando una de estas opciones:
- Clúster de Kafka autogestionado: Consulte la documentación de Apache Kafka. Establezca message.max.bytes y replica.fetch.max.bytes en el broker, así como fetch.message.max.bytes en el consumidor, con valores suficientemente grandes para manejar el volumen del registro binario de TiDB. Para detalles de configuración, consulte CONFIGURATION.
- Instancia de ApsaraMQ for Kafka: Consulte la descripción general de inicio rápido. Despliegue la instancia en la misma VPC que el servidor de la base de datos de origen.
Cree un tema en el clúster de Kafka o en la instancia de ApsaraMQ for Kafka.

Importante
El tema debe tener exactamente una partición. DTS lee datos incrementales únicamente desde la partición cuyo ID es 0.
Instale TiCDC. Se recomienda utilizar TiUP para agregar un nuevo nodo TiCDC o escalar horizontalmente el nodo TiCDC existente en el clúster de TiDB. Para más detalles, consulte Desplegar y mantener TiCDC.
Replique los datos incrementales de la base de datos TiDB de origen hacia Kafka. Se recomienda utilizar tiup cdc cli changefeed create \ en la primera línea de comandos. Para más detalles, consulte Replicar datos a Kafka.

Compruebe que el servidor de la base de datos TiDB pueda conectarse al clúster de Kafka.

Permisos obligatorios

Base de datos	Permisos obligatorios
Base de datos TiDB	SELECT en los objetos a migrar; SHOW VIEW
Instancia de ApsaraDB RDS for MySQL	Permisos de lectura y escritura en la base de datos de destino

Para obtener ayuda sobre la creación y configuración de cuentas, consulte Create an account y Modify account permissions.

Facturación

Tipo de migración	Tarifa de configuración de instancia	Tarifa de tráfico por Internet
Migración de esquema + migración completa de datos	Gratuita	Se cobra cuando Access Method está configurado como Public IP Address. Consulte la descripción general de facturación.
Migración incremental de datos	De pago. Consulte la descripción general de facturación.	—

Operaciones SQL compatibles con la migración incremental

Tipo de operación	Sentencias SQL
DML	INSERT, UPDATE, DELETE
DDL	CREATE TABLE, DROP TABLE, ALTER TABLE, RENAME TABLE, TRUNCATE TABLE, CREATE VIEW, DROP VIEW, ALTER VIEW

Notas de uso

Límites de la base de datos de origen:

El servidor de 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.
Las tablas deben tener restricciones PRIMARY KEY o UNIQUE con todos los campos únicos. Las tablas sin estas restricciones pueden causar registros duplicados en el destino.
Al migrar con cambio de nombre de tabla o columna, una sola tarea admite hasta 1,000 tablas. Si tiene más de 1,000 tablas, ejecute varias tareas en lotes o migre a nivel de base de datos.
La migración incremental de datos requiere un clúster de Kafka con TiDB Binlog o TiCDC configurado (consulte Preparations).

Migración completa de datos:

Ejecute las migraciones fuera de horas pico, cuando la carga de CPU en ambas bases de datos sea inferior al 30%. DTS utiliza recursos de lectura y escritura en ambas bases de datos durante la migración completa.
Las operaciones INSERT simultáneas durante la migración completa causan fragmentación de tablas en el destino. Espere que el espacio de tablas de destino sea mayor que el de origen al finalizar la migración.
Evite escribir datos desde otras fuentes en el destino durante la migración para prevenir inconsistencias en los datos.

Migración incremental de datos:

Después de crear la tarea, realice operaciones en la base de datos de origen o inserte datos de prueba de inmediato. Esto actualiza la información de desplazamiento y evita fallos en la tarea por latencia excesiva.
DTS lee datos incrementales únicamente desde la partición 0 del tema de Kafka.

Consideraciones sobre tipos de datos y conjuntos de caracteres:

Los datos que contienen caracteres poco comunes o emojis (caracteres de 4 bytes) requieren que las tablas de destino utilicen el conjunto de caracteres UTF8mb4. Si utiliza la función de migración de esquema, establezca el parámetro character_set_server de la base de datos de destino en UTF8mb4.
Los nombres de columna en MySQL no distinguen entre mayúsculas y minúsculas. Escribir nombres de columna que difieran solo en capitalización en la misma tabla de destino puede producir resultados inesperados.
DTS utiliza ROUND(COLUMN, PRECISION) para recuperar valores FLOAT y DOUBLE. Precisión predeterminada: FLOAT = 38 dígitos, DOUBLE = 308 dígitos. Compruebe que estos ajustes de precisión cumplan con sus requisitos.

Después de la migración:

Cuando el Status de la tarea muestre Completed, ejecute ANALYZE TABLE <table_name> para verificar que los datos se escribieron en disco. Un cambio por alta disponibilidad (HA switchover) en la base de datos MySQL de destino puede provocar que los datos existan solo en memoria, lo cual deriva en pérdida de datos.
DTS intenta reanudar las tareas con errores durante un máximo de 7 días. Antes de cambiar las cargas de trabajo a la base de datos de destino, detenga o libere cualquier tarea con errores, o ejecute REVOKE para eliminar los permisos de escritura de DTS en el destino. De lo contrario, una tarea reanudada podría sobrescribir los datos del destino con los del origen.
Las sentencias DDL que fallan en el destino no detienen la tarea de DTS. Consulte las sentencias DDL con errores en los registros de la tarea. Para más detalles, consulte Ver registros de tareas.
Si una tarea de DTS falla, el soporte de DTS intentará restaurarla dentro de un plazo de 8 horas. La tarea podría reiniciarse y sus parámetros (no los de la base de datos) podrían modificarse durante la restauración. Para conocer los parámetros que pueden modificarse, consulte Modificar parámetros de instancia.
Si el nombre de la base de datos de origen no cumple con las convenciones de nomenclatura de ApsaraDB RDS for MySQL, cree primero la base de datos de destino y utilice la función de asignación de nombres de objetos para renombrarla durante la configuración de la tarea. Para más detalles, consulte Manage databases y Asignar nombres de objetos.

Configurar y ejecutar la tarea de migración

Paso 1: Ir a la página Data Migration

Utilice una de estas consolas:

Consola de DTS:

Inicie sesión en la consola de DTS.
En el panel de navegación izquierdo, haga clic en Data Migration.
En la esquina superior izquierda, seleccione la región donde reside la instancia de migración.

Consola de Data Management Service (DMS):

Los pasos reales pueden variar según el modo y el diseño de la consola DMS. Para más detalles, consulte Modo simple y Personalizar el diseño y estilo de la consola DMS .

Inicie sesión en la consola de DMS.
En la barra de navegación superior, vaya a Data + AI > DTS (DTS) > Data Migration.
En la lista desplegable junto a Data Migration Tasks, seleccione la región donde reside la instancia de migración.

Paso 2: Crear la tarea y configurar las bases de datos de origen y destino

Haga clic en Create Task.
Configure las bases de datos de origen y destino con los siguientes parámetros:

Configuración de la tarea:

Parámetro	Descripción
Task Name	Nombre para la tarea de DTS. DTS genera un nombre automáticamente. Especifique un nombre descriptivo para identificar fácilmente la tarea. El nombre no necesita ser único.

Base de datos de origen:

Parámetro	Descripción
Select Existing Connection	Si la instancia de TiDB está registrada en DTS, selecciónela de la lista y DTS completará automáticamente los parámetros de conexión. De lo contrario, configure los parámetros siguientes. En la consola DMS, utilice la lista Select a DMS database instance.
Database Type	Seleccione TiDB.
Access Method	Seleccione el método de acceso según dónde esté desplegado TiDB. Este ejemplo utiliza Self-managed Database on ECS. Para otros métodos de acceso, complete primero la configuración del entorno requerida. Consulte Preparation overview.
Instance Region	La región donde reside la base de datos TiDB.
ECS Instance ID	El ID de la instancia ECS que aloja la base de datos TiDB.
Port Number	El puerto del servicio TiDB. Valor predeterminado: 4000.
Database Account	La cuenta de TiDB. Consulte Permissions required para ver los permisos obligatorios.
Database Password	La contraseña de la cuenta de TiDB.
Migrate Incremental Data	Seleccione Yes para habilitar la migración incremental de datos y luego introduzca la información del clúster de Kafka en la sección Kafka cluster parameters. Seleccione No para realizar solo una migración completa.

Base de datos de destino:

Parámetro	Descripción
Select Existing Connection	Si la instancia RDS está registrada en DTS, selecciónela de la lista. De lo contrario, configure los parámetros siguientes. En la consola DMS, utilice la lista Select a DMS database instance.
Database Type	Seleccione MySQL.
Access Method	Seleccione Alibaba Cloud Instance.
Instance Region	La región donde reside la instancia de ApsaraDB RDS for MySQL de destino.
Replicate Data Across Alibaba Cloud Accounts	Seleccione No para migraciones dentro de la misma cuenta.
RDS Instance ID	El ID de la instancia de ApsaraDB RDS for MySQL de destino.
Database Account	La cuenta de la base de datos de destino. Consulte Permissions required.
Database Password	La contraseña de la cuenta de la base de datos de destino.
Encryption	Seleccione Non-encrypted o SSL-encrypted. Para usar cifrado SSL, habilítelo en la instancia RDS antes de configurar la tarea. Consulte Usar un certificado en la nube para habilitar el cifrado SSL.

Paso 3: Probar la conectividad

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

Los bloques CIDR de los servidores DTS deben agregarse (automática o manualmente) a la configuración de seguridad tanto de la base de datos de origen como de la de destino. Para más detalles, consulte Agregar los bloques CIDR de los servidores DTS .

Paso 4: Configurar los objetos a migrar

En la página Configure Objects, establezca los siguientes parámetros:

Parámetro	Descripción
Migration Types	Seleccione los tipos de migración según su ruta: <br>- Schema Migration + Full Data Migration: Solo migración completa.<br>- Schema Migration + Full Data Migration + Incremental Data Migration: Migración completa + incremental para una migración sin tiempo de inactividad.<br><br> Nota Si omite Schema Migration, cree la base de datos y las tablas de destino antes de iniciar la tarea, y habilite la asignación de nombres de objetos en Selected Objects. Si omite Incremental Data Migration, deje de escribir en la base de datos de origen durante la migración para mantener la consistencia de los datos.
Processing Mode of Conflicting Tables	Precheck and Report Errors (recomendado): Falla la comprobación previa si existen tablas con nombres idénticos tanto en el origen como en el destino. Utilice la asignación de nombres de objetos para renombrar las tablas en conflicto. Consulte Asignar nombres de objetos. <br><br>Ignore Errors and Proceed: Omite la comprobación previa de nombres de tabla idénticos. Úselo con precaución, ya que puede causar inconsistencia en los datos. Durante la migración completa, se conservan los registros existentes en el destino. Durante la migración incremental, los registros existentes se sobrescriben. Si los esquemas difieren, solo se migran columnas específicas o la tarea podría fallar.
Capitalization of Object Names in Destination Instance	Controla el uso de mayúsculas en los nombres de bases de datos, tablas y columnas en el destino. La opción DTS default policy está seleccionada de forma predeterminada. Consulte Especificar el uso de mayúsculas en nombres de objetos.
Source Objects	Seleccione tablas o bases de datos en la sección Source Objects y luego haga clic en para agregarlos a Selected Objects.
Selected Objects	- Para renombrar un solo objeto, haga clic derecho sobre él en Selected Objects. Consulte Asignar el nombre de un solo objeto.<br>- Para renombrar varios objetos a la vez, haga clic en Batch Edit. Consulte Asignar múltiples nombres de objetos a la vez.<br>- Para filtrar filas, haga clic derecho en una tabla y specify filter conditions.<br><br> Nota Renombrar un objeto puede afectar a otros objetos que dependan de él.

Paso 5: Configurar ajustes avanzados

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

Parámetro	Descripción
Retry Time for Failed Connections	Tiempo durante el cual DTS reintenta conexiones fallidas después de iniciar la tarea. Valores válidos: 10–1,440 minutos. Valor predeterminado: 720. Establézcalo en 30 minutos como mínimo. DTS reanuda la tarea si la reconexión tiene éxito dentro de esta ventana; de lo contrario, la tarea falla.<br><br> Nota Si varias tareas comparten la misma base de datos de origen o destino, el tiempo de reintento establecido más recientemente se aplica a todas ellas. DTS cobra por el uso de la instancia durante los reintentos.
Retry Time for Other Issues	Tiempo durante el cual DTS reintenta operaciones DDL o DML fallidas. Valores válidos: 1–1,440 minutos. Valor predeterminado: 10. Establézcalo en 10 minutos como mínimo. Este valor debe ser menor que Retry Time for Failed Connections.
Enable Throttling for Full Data Migration	Limita el uso de recursos durante la migración completa para reducir la carga en las bases de datos. Configure Queries per second (QPS) to the source database, RPS of Full Data Migration y Data migration speed for full migration (MB/s). Disponible solo cuando se selecciona Full Data Migration.
Enable Throttling for Incremental Data Migration	Limita el uso de recursos durante la migración incremental. Configure RPS of Incremental Data Migration y Data migration speed for incremental migration (MB/s). Disponible solo cuando se selecciona Incremental Data Migration.
Environment Tag	Etiqueta opcional para identificar la instancia de DTS.
Configure ETL	Habilite la función de extracción, transformación y carga (ETL) para transformar datos durante la migración. Seleccione Yes e introduzca las sentencias de procesamiento en el editor de código. Consulte ¿Qué es ETL? y Configurar ETL.
Monitoring and Alerting	Configure alertas para fallos en la tarea o latencia de migración que supere un umbral. Seleccione Yes y configure el umbral de alerta y los ajustes de notificación. Consulte Configurar monitoreo y alertas.

Paso 6: Configurar la verificación de datos (opcional)

Haga clic en Next Step: Data Verification para configurar una tarea de verificación de datos. Para más detalles, consulte Configurar una tarea de verificación de datos.

Paso 7: Guardar la configuración y ejecutar la comprobación previa

Para previsualizar los parámetros de API necesarios para configurar esta tarea mediante programación, pase el cursor sobre Next: Save Task Settings and Precheck y haga clic en Preview OpenAPI parameters.
Para continuar, haga clic en Next: Save Task Settings and Precheck.

DTS ejecuta una comprobación previa antes de iniciar la migración. La tarea no puede comenzar hasta que esta comprobación se complete correctamente.

Si la comprobación previa falla, haga clic en View Details junto al elemento fallido, resuelva el problema y luego haga clic en Precheck Again .

Para alertas de comprobación previa: si la alerta no se puede ignorar, corrija el problema y vuelva a ejecutar la comprobación. Si se puede ignorar, haga clic en Confirm Alert Details , luego en Ignore , después en OK y finalmente en Precheck Again . Ignorar alertas puede causar inconsistencia en los datos.

Paso 8: Adquirir la instancia e iniciar la migración

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

En la página Purchase Instance, configure lo siguiente:

Parámetro	Descripción
Resource Group	El resource group para la instancia de migración. Valor predeterminado: default resource group. Consulte ¿Qué es Resource Management?
Instance Class	La velocidad de migración depende de la clase de instancia. Consulte Clases de instancias de migración de datos para seleccionar una clase adecuada a su carga de trabajo.

Lea y acepte los Data Transmission Service (Pay-as-you-go) Service Terms marcando la casilla correspondiente.
Haga clic en Buy and Start y luego haga clic en OK en el cuadro de diálogo de confirmación.

Monitoree la tarea en la página Data Migration:

Solo migración completa: La tarea se detiene automáticamente al finalizar. El Status muestra Completed.
Migración completa + incremental: La tarea se ejecuta continuamente. El Status muestra Running.

Parámetros del clúster de Kafka

Cuando Migrate Incremental Data está configurado como Yes, configure el clúster de Kafka en la sección de la base de datos de origen:

Parámetro	Descripción
Kafka Cluster Type	Ubicación de despliegue del clúster de Kafka. Este ejemplo utiliza Self-managed Database on ECS. Si selecciona Express Connect, VPN Gateway, or Smart Access Gateway, seleccione también una VPC en Connected VPC y especifique Domain Name or IP.
Kafka Data Source Component	Seleccione según el método utilizado en Preparations: Use the default binlog format of the TiDB database. (TiDB Binlog) o Use the TiCDC Canal-JSON format. (TiCDC).
ECS Instance ID	El ID de la instancia ECS que aloja el clúster de Kafka.
Port Number	El puerto del servicio Kafka.
Kafka Cluster Account	Nombre de usuario de Kafka. Déjelo en blanco si la autenticación no está habilitada.
Kafka Cluster Password	Contraseña de Kafka. Déjela en blanco si la autenticación no está habilitada.
Kafka Version	Versión de Kafka. Si la versión es 1.0 o posterior, seleccione 1.0.
Encryption	Seleccione Non-encrypted o SCRAM-SHA-256 según sus requisitos de seguridad.
Topic	Tema que recibe los datos incrementales. El tema debe tener solo una partición.

Pasos siguientes

Una vez que el estado de la tarea de migración muestre Completed o la latencia de la migración incremental llegue a cero, cambie su aplicación a la base de datos de destino:

Detenga las escrituras en la base de datos TiDB de origen.
Espere a que la latencia de la migración incremental llegue a 0 y la tarea procese todos los cambios restantes.
Actualice las cadenas de conexión de su aplicación para que apunten a la instancia de ApsaraDB RDS for MySQL.
Ejecute ANALYZE TABLE <table_name> en las tablas clave para verificar la integridad de los datos.
Detenga o libere la tarea de migración de DTS.