Data Transmission Service:Migrar datos de una base de datos TiDB autogestionada a un clúster de PolarDB for MySQL

Límites de la base de datos de origen

• Ancho de banda de salida: El servidor de la base de datos de origen debe tener suficiente ancho de banda de salida. Un ancho de banda insuficiente reduce la velocidad de migración.

• Clave primaria o restricción UNIQUE: Las tablas deben tener una PRIMARY KEY o una restricción UNIQUE con todos los campos únicos. Sin estas restricciones, la base de datos de destino podría contener registros duplicados.

• Límite de tablas por tarea: Al migrar tablas individuales con ediciones a nivel de columna (como cambiar el nombre de columnas), una sola tarea admite hasta 1,000 tablas. Si tiene más de 1,000 tablas, divida el trabajo en varias tareas o migre toda la base de datos.

• Restricciones de DDL durante la migración: Durante la migración de esquemas y la migración completa de datos, no ejecute operaciones DDL que modifiquen el esquema de la base de datos o de las tablas. La tarea de migración fallará si se detectan operaciones DDL.

• Índices de prefijo: Los metadatos de TiDB no almacenan las longitudes de los índices de prefijo. Después de la migración, estas longitudes se pierden, lo que podría impedir que la instancia se ejecute. Corrija manualmente las longitudes de los índices de prefijo en las tablas afectadas después de la migración.

• Requisitos de datos incrementales: La migración incremental de datos requiere un clúster de Kafka y componentes de TiDB Binlog o TiCDC. Consulte (Opcional) Configurar la recopilación de datos incrementales.

Otros límites

• Incremental data partition: DTS lee los datos incrementales únicamente desde la partición con ID 0 en el tema de Kafka.

• Inicialización de posición: Después de crear una tarea con migración incremental, realice cambios o inserte datos de prueba en la base de datos de origen de inmediato para actualizar la información de posición. De lo contrario, la tarea podría fallar debido a una latencia excesiva.

• Caracteres de 4 bytes: Si los datos incluyen caracteres poco comunes o emoji (caracteres de 4 bytes), 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 también el parámetro de instancia character_set_server en UTF8mb4 en la base de datos de destino.

• Uso de recursos en la migración completa: La migración completa de datos consume recursos de lectura y escritura tanto en la base de datos de origen como en la de destino, lo que aumenta su carga. Evalúe el rendimiento de la base de datos antes de migrar y ejecute la migración completa en horas de baja demanda (por ejemplo, cuando la carga de CPU sea inferior al 30%).

• Tamaño del tablespace después de la migración completa: Las operaciones INSERT simultáneas durante la migración completa de datos provocan fragmentación en las tablas. El tablespace en la base de datos de destino será mayor que en la base de datos de origen una vez completada la migración.

• Escrituras en el destino durante la migración: Escribir en la base de datos de destino durante la migración puede causar inconsistencia de datos entre el origen y el destino.

• Precisión de FLOAT y DOUBLE: DTS utiliza ROUND(COLUMN,PRECISION) para leer valores FLOAT y DOUBLE. La precisión predeterminada es de 38 dígitos para FLOAT y 308 dígitos para DOUBLE. Compruebe que estos ajustes de precisión cumplen sus requisitos.

• Reanudación automática: DTS intenta reanudar automáticamente las tareas que fallaron en los últimos siete días. Antes de transferir las cargas de trabajo a la instancia de destino, detenga o libere la tarea de DTS, o ejecute REVOKE para eliminar los permisos de escritura de la cuenta de DTS en la instancia de destino.

• Fallos en DDL: Si una sentencia DDL falla en la base de datos de destino, la tarea de DTS continúa ejecutándose. Consulte las sentencias DDL fallidas en los registros de la tarea. Véase Ver registros de tareas.

• Intervención de soporte técnico: Si una tarea de DTS falla, el soporte técnico intentará restaurarla en un plazo de 8 horas. Durante la restauración, la tarea podría reiniciarse y modificarse algunos parámetros de la tarea (no de la base de datos). Para conocer los parámetros que podrían modificarse, consulte la sección Modificar parámetros de instancia.

Paso 1: Configurar un clúster de Kafka

Utilice una de las siguientes opciones:

• Clúster de Kafka autogestionado: Despliegue Apache Kafka siguiendo la documentación de Apache Kafka.

  Aviso

  Para manejar el volumen de datos del registro binario de TiDB, aumente los siguientes parámetros en su configuración de Kafka. Consulte Configuración de Kafka.

  Componente	Parámetro	Motivo
  Broker	message.max.bytes	Establece el tamaño máximo de mensaje que acepta el broker. Los eventos del registro binario de TiDB pueden ser grandes, por lo que el límite predeterminado provoca fallos de escritura.
  Broker	replica.fetch.max.bytes	Establece el número máximo de bytes que un seguidor puede obtener por solicitud. Debe ser al menos igual a message.max.bytes para replicar mensajes de gran tamaño.
  Consumer	fetch.message.max.bytes	Establece el número máximo de bytes que un consumidor obtiene por partición. Debe ser al menos igual a message.max.bytes para que DTS pueda leer eventos completos.

• Message Queue for Apache Kafka: Utilice el servicio administrado de Kafka de Alibaba Cloud. Consulte Getting started.

  Despliegue la instancia de Message Queue for Apache Kafka en la misma virtual private cloud (VPC) que el servidor de la base de datos de origen para reducir la latencia de red y garantizar una conectividad estable.

Paso 2: Crear un tema de Kafka

Cree un tema en el clúster de Kafka o en la instancia de Message Queue for Apache Kafka.

Paso 3: Configurar TiDB Binlog o TiCDC

Elija un método según su entorno:

<details> <summary>Opción A: TiDB Binlog</summary>

Para minimizar el impacto de la latencia de red, despliegue el componente Pump, el componente Drainer y el clúster de Kafka en servidores que compartan la misma red interna que el servidor de la base de datos TiDB de origen.

1. Despliegue los componentes Pump y Drainer. Consulte Despliegue de clúster de TiDB Binlog.

2. Edite el archivo de configuración de Drainer para establecer Kafka como salida. Consulte Desarrollo personalizado de Kafka.Kafka Custom Development

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

4. Agregue los bloques CIDR de los servidores DTS a la lista blanca de la base de datos TiDB. Consulte Agregar los bloques CIDR de los servidores DTS.

</details>

<details> <summary>Opción B: TiCDC</summary>

1. Instale el componente TiCDC. Utilice TiUP para agregar o escalar horizontalmente TiCDC en su clúster de TiDB existente. Consulte Desplegar TiCDC.

2. Replicar datos incrementales a Kafka utilizando tiup cdc cli changefeed create \ como primer comando. Consulte Replicar datos a Kafka.

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

</details>

Paso 1: Ir a la página de migración de datos

Utilice uno de los siguientes métodos:

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

1. Haga clic en Create Task.

2. En la página de configuración de la tarea, configure las bases de datos de origen y destino.

Parámetros de la base de datos de origen

Parámetros de la base de datos de destino

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 Test Connectivity.

Asegúrese de que los bloques CIDR de los servidores DTS estén agregados a la configuración de seguridad de las bases de datos de origen y destino. Consulte Agregar los bloques CIDR de los servidores DTS .

Paso 4: Configurar los objetos de migración

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

Tipos de migración y manejo de conflictos

Selección de objetos

Parámetro	Descripción
Source Objects	Seleccione las tablas o bases de datos a migrar. Haga clic en para mover los objetos seleccionados a Selected Objects.
Selected Objects	Haga clic derecho en un objeto para cambiarle el nombre. Consulte Asignar nombre a un solo objeto. Haga clic en Batch Edit para cambiar el nombre de varios objetos a la vez. Consulte Asignar nombres a múltiples objetos simultáneamente. Haga clic derecho en una tabla para configure a WHERE filter condition. Nota Cambiar el nombre de un objeto puede impedir que se migren los objetos dependientes. Nota

1. Haga clic en Next: Advanced Settings.

Advanced settings

1. Haga clic en Next Step: Data Verification para configurar la verificación de datos. Consulte Configurar una tarea de verificación de datos.

Paso 5: Ejecutar la verificación previa

1. Para previsualizar los parámetros de API de esta tarea, mueva el puntero sobre Next: Save Task Settings and Precheck y haga clic en Preview OpenAPI parameters.

2. Haga clic en Next: Save Task Settings and Precheck.

DTS ejecuta una verificación previa antes de iniciar la migración. La tarea solo comienza después de aprobar dicha verificación.

Para los elementos de verificación previa fallidos, haga clic en View Details para diagnosticar el problema, resuélvalo y luego ejecute nuevamente la verificación previa.

Para elementos de alerta: si la alerta no se puede ignorar, corrija el problema y vuelva a ejecutar la verificación previa. Si la alerta se puede ignorar, haga clic en Confirm Alert Details , luego haga clic en Ignore > OK > Precheck Again .

Paso 6: Adquirir e iniciar la instancia

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

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

1. Lea y acepte los Data Transmission Service (Pay-as-you-go) Service Terms seleccionando la casilla de verificación.

2. Haga clic en Buy and Start, luego haga clic en OK.

La tarea aparecerá en la página Data Migration. Supervise su progreso desde allí.