Data Transmission Service:Migrate data from an ApsaraDB RDS for MySQL instance to an ApsaraDB for ClickHouse cluster

Clúster de destino

• El clúster de destino de ApsaraDB for ClickHouse debe ejecutar la versión 20.8 o posterior. Consulte Create a cluster.

• El espacio de almacenamiento en el clúster de destino debe superar al almacenamiento utilizado por la instancia RDS MySQL de origen.

Permisos de la cuenta de la base de datos de origen

La cuenta de la base de datos de origen debe tener permisos de lectura sobre los objetos que se van a migrar. Si la cuenta no se creó a través de la consola de RDS, otorgue manualmente los siguientes permisos:

GRANT REPLICATION CLIENT, REPLICATION SLAVE, SHOW VIEW, SELECT ON *.* TO '<account>'@'%';

Consulte Create an account y Modify account permissions.

Permisos de la cuenta del clúster de destino

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

Si planea incluir la migración incremental de datos, configure los siguientes parámetros en la instancia MySQL de origen.

Habilitar la retención del registro binario

El periodo mínimo de retención depende del tipo de origen:

• ApsaraDB RDS for MySQL: Los registros binarios deben conservarse durante al menos 3 días (se recomiendan 7 días).

• MySQL autogestionado: Los registros binarios deben conservarse durante al menos 7 días.

Si los registros se conservan por menos tiempo que el mínimo requerido, la tarea de migración podría fallar o provocar pérdida de datos. Para establecer el periodo de retención de una instancia RDS MySQL, consulte Configurar parámetros para la eliminación automática de archivos de registro binario de una instancia RDS.

Configurar el formato del registro binario

Establezca los siguientes parámetros en la instancia MySQL de origen:

Esta configuración es necesaria para que DTS pueda leer los datos de cambios a nivel de fila. Si no se establece correctamente, la verificación previa fallará y la tarea de migración no podrá iniciarse.

Si el origen es una base de datos MySQL autogestionada implementada en un clúster de doble primario, establezca también log_slave_updates = ON para que DTS pueda obtener todos los registros binarios.

Restricciones de la base de datos de origen

• Límite de migración a nivel de tabla: Una sola tarea de migración admite un máximo de 1,000 tablas cuando se utiliza la asignación de nombres de objetos. Si supera este límite, divida las tablas en varias tareas o migre toda la base de datos.

• Columnas invisibles (MySQL 8.0.23 y posteriores): DTS no puede leer columnas invisibles, lo que provoca pérdida de datos. Para hacer visible una columna, ejecute ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE;. Las tablas sin claves primarias explícitas generan automáticamente claves primarias invisibles; hágales visibles también. Consulte Invisible Columns y Generated Invisible Primary Keys.

• RDS MySQL V5.6 de solo lectura: Este tipo de instancia no registra registros de transacciones y no puede usarse como origen para la migración incremental.

• Instancias con EncDB habilitado: No se admite la migración completa de datos. Las instancias con Transparent Data Encryption (TDE) habilitado admiten la migración de esquemas, la migración completa de datos y la migración incremental de datos.

• Restricciones de DDL durante la migración: No ejecute instrucciones DDL mientras se realiza la migración del esquema o la migración completa de datos. En caso de migración solo completa, no escriba en la base de datos de origen durante el proceso.

• Restauraciones de copias de seguridad físicas y operaciones en cascada: Los datos de cambio generados por restauraciones de copias de seguridad físicas u operaciones en cascada en el origen no se registran ni se migran al destino mientras la instancia de migración está en ejecución. Si esto ocurre, puede realizar nuevamente la migración completa de datos, siempre que su negocio no se vea afectado.

Otras restricciones

• No se admite la migración de INDEX, PARTITION, VIEW, PROCEDURE, FUNCTION, TRIGGER ni claves externas.

• La operación RENAME TABLE no se puede migrar.

• Si la base de datos de origen tiene operaciones de cambio DDL en línea en modo de tabla temporal, como en escenarios de fusión de múltiples tablas, podría producirse pérdida de datos en la base de datos de destino o fallos en la instancia de migración.

• Si el origen contiene cambios DDL en línea realizados con pt-online-schema-change, podría ocurrir pérdida de datos o fallos en la migración. Si migra una o más tablas en lugar de una base de datos completa, no utilice pt-online-schema-change para realizar operaciones DDL en línea sobre los objetos de migración en la base de datos de origen; de lo contrario, la migración fallará. Los cambios DDL en línea realizados con DMS o gh-ost son compatibles: DTS migra la instrucción DDL original sin copiar los datos de la tabla temporal, pero esto podría causar bloqueos de tablas en el destino. Puede utilizar Data Management (DMS) para realizar operaciones DDL en línea.

• Si las instrucciones DDL en el origen no siguen la sintaxis estándar de MySQL, la tarea de migración podría fallar o perderse datos.

• El número de bases de datos a migrar no debe exceder 256 (el límite de ClickHouse).

• Los nombres de bases de datos, tablas y columnas deben cumplir con ApsaraDB for ClickHouse naming conventions.

• Durante la migración del esquema, DTS agrega los campos _sign, _is_deleted y _version a las tablas de destino. Si omite la migración del esquema, cree manualmente las tablas de destino e incluya estos campos. Consulte Appendix: table and field information.

• No se deben escribir datos provenientes de fuentes distintas a DTS en la base de datos de destino mientras la migración esté en curso.

• Si una tarea de DTS falla durante su ejecución, el soporte técnico de DTS intentará restaurarla en un plazo de 8 horas. Durante la restauración, la tarea podría reiniciarse y sus parámetros podrían modificarse. Nota: solo se pueden modificar los parámetros de la tarea de DTS, no los de las bases de datos. Los parámetros que pueden modificarse incluyen, entre otros, los descritos en la sección Modificar parámetros de instancia.

Restricciones específicas de ClickHouse

• Rango de datos de tipo temporal: Los tipos temporales de ClickHouse tienen límites de rango. Los datos de origen fuera de estos rangos se escriben incorrectamente. Consulte Appendix: time information.

• Clave de partición: No puede ser un campo anulable. Tipos compatibles: BIGINT, INT, TIMESTAMP, DATETIME, DATE.

• Máximo de bases de datos: 256.

Casos especiales

Orígenes MySQL autogestionados

• Si realiza un cambio de primario/secundario en la base de datos de origen mientras se ejecuta la tarea de migración de datos, la tarea fallará.

• DTS calcula la latencia de migración basándose en la marca de tiempo del último dato migrado en el destino y la marca de tiempo actual en el origen. Si no se realiza ninguna operación DML en el origen durante un periodo prolongado, la latencia de migración podría ser inexacta. Para actualizar la latencia, ejecute una operación DML en el origen. Si selecciona una base de datos completa como objeto de migración, puede crear una tabla de latidos que se actualice cada segundo.

• DTS ejecuta CREATE DATABASE IF NOT EXISTS \ test\`` en la base de datos de origen de forma programada para avanzar la posición del archivo de registro binario.

Orígenes ApsaraDB RDS for MySQL

• En la migración incremental de datos, no se puede utilizar una instancia de ApsaraDB RDS for MySQL V5.6 de solo lectura como base de datos de origen.

• DTS ejecuta CREATE DATABASE IF NOT EXISTS \ test\`` en la base de datos de origen de forma programada para avanzar la posición del archivo de registro binario.

Paso 1: Abrir la página Data Migration

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

Paso 2: Configurar la tarea

Haga clic en Create Task para abrir la página de configuración de la tarea. Configure los parámetros descritos en la siguiente tabla.

Paso 3: Probar la conectividad

Haga clic en Test Connectivity and Proceed en la parte inferior de la página.

Los bloques CIDR de los servidores de DTS deben agregarse a la configuración de seguridad tanto de la base de datos de origen como de la de destino. Consulte Agregar los bloques CIDR de los servidores de DTS . Si el origen o el destino es una base de datos autogestionada que no utiliza el método de acceso Alibaba Cloud Instance , haga clic en Test Connectivity en el cuadro de diálogo CIDR Blocks of DTS Servers .

Paso 4: Seleccionar los objetos a migrar

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

Paso 5: Configurar ajustes avanzados

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

Paso 6: Configurar campos de tabla de ClickHouse

Haga clic en Next: Configure Database and Table Fields para establecer el Type, Primary Key Column, Sort Key, Distribution Key y Partition Key para cada tabla de destino en ClickHouse.

• DTS proporciona una configuración predeterminada. Para revisar o modificar todas las tablas, establezca Definition Status en All.

• Primary Key Column y Sort Key admiten claves compuestas; seleccione varios campos de la lista desplegable.

• Partition Key debe ser una o más columnas de Primary Key Column. Solo se admiten los tipos BIGINT, INT, TIMESTAMP, DATETIME y DATE. Los campos anulables no pueden utilizarse como clave de partición. Se permite dejar la clave de partición en blanco.

• Distribution Key acepta únicamente un solo campo.

Para obtener detalles sobre claves primarias, claves de ordenamiento y claves de partición en ClickHouse, consulte CREATE TABLE.

Paso 7: Ejecutar una verificación previa

Haga clic en Next: Save Task Settings and Precheck.

Para ver los parámetros de API correspondientes a esta configuración de tarea, pase el cursor sobre Next: Save Task Settings and Precheck y haga clic en Preview OpenAPI parameters .

DTS ejecuta una verificación previa antes de iniciar la migración. Si la verificación falla:

1. Haga clic en View Details junto al elemento fallido.

2. Corrija el problema basándose en los resultados de la verificación.

3. Haga clic en Precheck Again.

Si un elemento de alerta puede ignorarse: haga clic en Confirm Alert Details > Ignore > OK > Precheck Again. Ignorar alertas puede causar inconsistencia en los datos.

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

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

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

   Sección	Parámetro	Descripción
   New Instance Class	Resource Group	El resource group para la instancia de migración. Predeterminado: default resource group. Consulte What is Resource Management?
   	Instance Class	La clase de instancia determina la velocidad de migración. 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 > OK.

Consultar correctamente los datos migrados

DTS utiliza el motor ReplicatedReplacingMergeTree y agrega los campos _sign, _is_deleted y _version a las tablas de destino. Sin la palabra clave FINAL, las consultas podrían devolver filas duplicadas o eliminadas. Utilice siempre FINAL y filtre por _sign:

SELECT * FROM <table_name> FINAL WHERE _sign > 0;

La condición WHERE _sign > 0 filtra las filas marcadas como eliminadas.

Requisitos de tabla para creación manual

Si omite la migración de esquemas, cree las tablas de destino antes de iniciar la tarea. Las tablas deben cumplir con estos requisitos.

• Community Edition: Cree una tabla local y una tabla distribuida. El nombre de la tabla distribuida debe coincidir con el nombre de la tabla de origen. El nombre de la tabla local debe ser <distributed_table_name>_local.

• Enterprise Edition: Cree una tabla con el mismo nombre que la tabla de origen.

Campos gestionados por DTS

DTS agrega automáticamente los siguientes campos a las tablas de destino durante la migración del esquema.

Lógica de cálculo de la clave de partición