Data Transmission Service:Sincronización de datos de una instancia de ApsaraDB RDS for MySQL a una instancia de PolarDB-X 1.0

ApsaraDB RDS for MySQL

El registro binario se habilita de forma predeterminada en las instancias de ApsaraDB RDS for MySQL. Asegúrese de que:

• El parámetro binlog_row_image esté establecido en full. De lo contrario, se generará un error en la comprobación previa y la tarea no podrá iniciarse. Consulte Set instance parameters.

• Los registros binarios locales se conserven durante como mínimo 3 días (se recomiendan 7 días). Si los registros se purgan antes de que DTS pueda leerlos, la tarea terminará con errores. En casos extremos, esto puede provocar pérdida o inconsistencia de datos. Las tareas que fallen por una retención insuficiente de registros no están cubiertas por el acuerdo de nivel de servicio (SLA) de DTS. Para establecer el Retention Period de los registros binarios locales, consulte Automatically delete local logs.

Las instancias de solo lectura de ApsaraDB RDS for MySQL 5.6 no registran registros de transacciones, por lo que no pueden utilizarse como base de datos de origen.

MySQL administrado por el usuario

Para una base de datos MySQL administrada por el usuario, configure los siguientes parámetros:

Conserve los registros binarios durante como mínimo 7 días. Si los registros se purgan antes de que DTS pueda leerlos, la tarea terminará con errores. Los problemas derivados de una retención insuficiente de registros no están cubiertos por el SLA de DTS.

Requisitos adicionales:

• Arquitectura principal/principal: Habilite el parámetro log_slave_updates para que DTS pueda obtener todos los registros binarios de ambos nodos. Consulte Create a database account for a self-managed MySQL database and configure binary logging.

• Instancias de Amazon Aurora MySQL o en modo clúster: Asegúrese de que el nombre de dominio o la dirección IP configurados para la tarea apunten siempre al nodo de lectura/escritura (RW). De lo contrario, es posible que la tarea no se ejecute correctamente.

Límites de la base de datos de origen

• El servidor donde se despliega la base de datos de origen debe contar con suficiente ancho de banda de salida. Un ancho de banda insuficiente reduce la velocidad de sincronización.

• Las tablas que se van a sincronizar deben tener una clave primaria o una restricción UNIQUE con valores de campo únicos. Las tablas sin estas restricciones pueden generar datos duplicados en el destino.

• Solo es posible seleccionar tablas como objetos de sincronización.

• Cuando se utiliza la asignación de nombres de objetos (por ejemplo, para asignar nombres de tablas o columnas), una sola tarea admite un máximo de 1,000 tablas. Si necesita sincronizar más de 1,000 tablas con asignación de nombres, divídalas en varias tareas.

• La clase de almacenamiento de la instancia de PolarDB-X 1.0 debe ser RDS MySQL (una instancia de RDS personalizada privada). PolarDB MySQL no es compatible.

• No ejecute operaciones DDL durante la sincronización completa de datos, ya que esto provocará que la tarea termine con errores.

  Durante la fase de sincronización completa, DTS consulta la base de datos de origen y puede generar bloqueos de metadatos que impidan ejecutar operaciones DDL en el origen.

• Los cambios de datos provenientes de operaciones no registradas en los registros binarios no se sincronizan. Esto incluye la recuperación de datos mediante copias de seguridad físicas y las operaciones en cascada.

  Si esto ocurre, quite la base de datos o tabla afectada de los objetos de sincronización y vuelva a agregarla, siempre que su operación comercial lo permita. Consulte Modify synchronization objects .

• Columnas invisibles (MySQL 8.0.23 y versiones posteriores): Si los datos que se van a sincronizan contienen columnas invisibles, DTS no podrá obtener la información de dichas columnas, lo cual puede causar pérdida de datos. Ejecute el siguiente comando para hacer visibles las columnas invisibles:

  ALTER TABLE <table_name> ALTER COLUMN <column_name> SET VISIBLE;

  Las tablas sin clave primaria generan automáticamente una clave primaria invisible que también debe hacerse visible. Consulte Invisible Columns y Generated Invisible Primary Keys.

• Si la tabla de destino de PolarDB-X 1.0 tiene habilitado el particionamiento automático (auto_partition=true), cada instrucción DDL ejecutada en el origen solo puede contener un elemento alter_specification. De lo contrario, DTS reportará un error (TDDL-4998: Multi alter specifications when create GSI not support yet). Para ejecutar una instrucción DDL que contenga varios elementos alter_specification, divida cada alter_specification en una instrucción DDL independiente y ejecútelas una por una. Para obtener más información, consulte ALTER TABLE.

Otros límites

• EncDB (siempre confidencial): La sincronización completa de datos no es compatible cuando la función siempre confidencial (EncDB) está habilitada en la instancia de origen de ApsaraDB RDS for MySQL.

  Las instancias con Transparent Data Encryption (TDE) habilitado admiten la sincronización de esquemas, la sincronización completa de datos y la sincronización incremental de datos.

• Si ejecuta operaciones DDL en línea que utilicen tablas temporales en la base de datos de origen, como la fusión de varias tablas, podrían perderse datos en la base de datos de destino o la instancia de DTS podría terminar con errores.

• No utilice herramientas como pt-online-schema-change para ejecutar operaciones DDL en línea sobre los objetos que se están sincronizando, ya que esto provocará que la tarea termine con errores.

• Escribir datos de otros orígenes en la base de datos de destino durante la sincronización puede generar inconsistencias en los datos.

• Evalúe el impacto en el rendimiento de las bases de datos de origen y destino antes de iniciar la sincronización. Siempre que sea posible, ejecute las tareas de sincronización fuera del horario de mayor demanda. La sincronización completa de datos consume recursos de lectura y escritura en ambas bases de datos, lo que puede aumentar la carga del servidor.

• Una vez finalizada la sincronización completa de datos, las operaciones INSERT simultáneas pueden provocar fragmentación en las tablas de destino. Por ello, el espacio de tablas utilizado en la base de datos de destino podría ser mayor que en la de origen.

• Si una instancia de DTS presenta errores, el equipo de soporte de DTS intentará recuperarla en un plazo de 8 horas. Las operaciones de recuperación pueden incluir el reinicio de la instancia o el ajuste de los parámetros de la instancia de DTS (no de los parámetros de la base de datos). Consulte Modify instance parameters.

Casos especiales para orígenes de MySQL administrados por el usuario

• Si ocurre una conmutación por error entre el nodo principal y el secundario en la base de datos de origen durante la sincronización, la tarea terminará con errores.

• La latencia de sincronización se calcula a partir de la diferencia entre la marca de tiempo actual y la del último registro de datos sincronizado. Si no se ejecutan operaciones DML en la base de datos de origen durante mucho tiempo, la latencia mostrada podría ser inexacta. Ejecute una operación DML en el origen para actualizar el valor de latencia.

  Si decide sincronizar toda la base de datos, cree una tabla de latidos. DTS actualiza o escribe en esta tabla cada segundo para mantener precisa la lectura de latencia.

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

Casos especiales para orígenes de ApsaraDB RDS for MySQL

• Las instancias de ApsaraDB RDS for MySQL que no registran registros de transacciones, como las instancias de solo lectura de ApsaraDB RDS for MySQL 5.6, no pueden utilizarse como base de datos de origen.

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

Paso 1: Acceder a la página Data Synchronization

Utilice la consola de DTS o la consola de DMS.

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, establezca los siguientes parámetros.

General

Base de datos de origen

Base de datos de destino

1. Haga clic en Test Connectivity and Proceed.

Asegúrese de que los bloques CIDR de los servidores de DTS estén agregados a la configuración de seguridad de las bases de datos de origen y destino. Consulte Add DTS server IP addresses to a whitelist . Si la base de datos de origen o destino está administrada por el usuario y no se accede a ella mediante Alibaba Cloud Instance , haga clic en Test Connectivity en el cuadro de diálogo CIDR Blocks of DTS Servers .

Paso 3: Configurar los objetos de sincronización

En el paso Configure Objects, establezca los siguientes parámetros.

Haga clic en Next: Advanced Settings.

Paso 4: Configurar los ajustes avanzados

Paso 5: Ejecutar la comprobación previa

Haga clic en Next: Save Task Settings and Precheck.

Para consultar los parámetros de API de esta configuración de tarea, coloque el puntero sobre Next: Save Task Settings and Precheck y haga clic en Preview OpenAPI parameters .

La tarea ejecuta una comprobación previa antes de iniciarse. Solo puede comenzar después de superar dicha comprobación.

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

• Si un elemento genera una alerta que puede ignorarse, haga clic en Confirm Alert Details, luego en Ignore > OK > Precheck Again. Ignorar elementos de alerta puede generar inconsistencia en los datos.

Paso 6: Adquirir la instancia

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

2. En la página de compra, configure los siguientes parámetros.

1. Lea y seleccione Data Transmission Service (Pay-as-you-go) Service Terms.

2. Haga clic en Buy and Start y luego en OK para confirmar.

La tarea aparecerá en la lista de tareas, donde podrá monitorear su progreso.