Data Transmission Service:Migrate data from a PolarDB-X 1.0 instance to an ApsaraDB RDS for MySQL instance

Source database requirements

• The server must have sufficient outbound bandwidth. Low bandwidth reduces migration speed.

• Tables must have PRIMARY KEY or UNIQUE constraints with all fields unique. Tables without these constraints may produce duplicate records in the destination.

• If you rename tables or columns during migration, a single task supports up to 1,000 tables. For more than 1,000 tables, split the workload across multiple tasks or migrate the entire database instead.

• Do not modify the source during migration: avoid upgrading or downgrading the instance, migrating frequently-updated tables, changing shard keys, or running DDL operations. Any of these will cause the migration task to fail.

• If you change the network type of the PolarDB-X 1.0 instance during migration, update the network connection settings of the migration task to match.

• For full data migration only: do not write data to the source during migration. Writing to the source during a full-only migration causes data inconsistency.

For incremental data migration, configure the following before you start:

• Binary logging must be enabled and binlog_row_image must be set to full. DTS fails the precheck if this is not set.

• Binary log retention must meet the minimum duration: If DTS cannot read the binary logs, the task fails and data inconsistency or loss may occur. After full data migration completes, you can reduce the retention period to more than 24 hours.

  Migration scope	Minimum retention
  Incremental data migration only	More than 24 hours
  Full data migration + incremental data migration	At least 7 days

Other limitations

• DTS does not migrate online DDL operations.

• DTS migrates foreign keys from the source to the destination during schema migration.

• If data contains 4-byte characters (rare characters or emojis), the destination tables must use the UTF8mb4 character set. If you use schema migration, set the character_set_server parameter in the destination to UTF8mb4.

• Column names that differ only in capitalization within the same destination table may produce unexpected results because MySQL column names are case-insensitive.

• If you use XA transactions in the source, DTS ensures incremental data consistency based on XA transaction continuity. If continuity is disrupted (for example, during disaster recovery), uncommitted XA transactions may be lost.

• DTS temporarily disables foreign key constraint checks and cascade operations at the session level during migration. If you run cascade or delete operations on the source during this time, data inconsistency may occur.

• During full data migration, concurrent INSERT operations cause table fragmentation. After migration completes, the destination tablespace size is larger than the source.

• DTS retries failed tasks for up to 7 days. Before switching workloads to the destination, stop or release any failed tasks, or run REVOKE to remove DTS write permissions on the destination. Otherwise, a resumed failed task may overwrite destination data with source data.

• After migration completes (task Status changes to Completed), run ANALYZE TABLE <table_name> to verify that data was written to disk. In some high availability (HA) switchover scenarios, data may exist only in memory and can be lost.

• If a DTS task fails, DTS technical support attempts to restore it within 8 hours. During restoration, the task may be restarted and its parameters may be modified. Database parameters are not modified.

• DTS periodically updates the dts_health_check.ha_health_check table in the source to advance the binary log position.

SQL operations supported for incremental migration

Step 1: Go to the Data Migration page

Step 2: Configure source and destination databases

1. Click Create Task.

2. Configure the source and destination databases using the parameters in the following table.

1. Click Test Connectivity and Proceed.

Make sure that the CIDR blocks of DTS servers are added to the security settings of the source and destination databases. See Add the CIDR blocks of DTS servers.

Step 3: Select objects and configure migration options

1. On the Configure Objects page, set the following parameters.

1. Click Next: Advanced Settings and configure the following parameters.

Step 4: Run the precheck and start migration

1. Click Next: Save Task Settings and Precheck.

   To view the API parameters for this configuration, hover over Next: Save Task Settings and Precheck and click Preview OpenAPI parameters before proceeding.

2. DTS runs a precheck automatically. If any items fail:

   • Click View Details next to the failed item, resolve the issue, and click Precheck Again.

   • If an item shows an alert that can be ignored, click Confirm Alert Details > Ignore > OK, then click Precheck Again. Ignoring alerts may cause data inconsistency.

3. Wait until Success Rate reaches 100%, then click Next: Purchase Instance.

4. On the Purchase Instance page, configure the following parameters.

1. Read and select Data Transmission Service (Pay-as-you-go) Service Terms, then click Buy and Start > OK.