Data Transmission Service:Migrate data from a PolarDB for MySQL cluster to a MaxCompute project

Task-blocking conditions (fix before starting)

These conditions cause the migration task to fail:

• The server on which the source database is deployed must have sufficient outbound bandwidth. Otherwise, the data migration speed decreases.

• Tables to be migrated must have a PRIMARY KEY or UNIQUE constraint with all fields unique. Without this, the destination may contain duplicate records.

• If you select tables as migration objects and need to rename tables or columns, a single task supports up to 1,000 tables. Tasks with more than 1,000 tables in this mode return a request error. Configure multiple tasks or migrate at the database level instead.

• For incremental data migration, binary logging must be enabled and the loose_polar_log_bin parameter must be set to on. If binary logging is not enabled, the precheck fails and the task cannot start. See Enable binary logging and Modify parameters.

• Do not execute DDL statements to change database or table schemas during schema migration or full data migration. The migration task fails if schemas change mid-task.

• Do not use tools such as pt-online-schema-change for online DDL operations on objects being migrated. The migration task fails.

Enabling binary logging on a PolarDB for MySQL cluster incurs storage charges for the binary log files.

Data integrity risks (review before starting)

These conditions may cause data inconsistency or loss:

• Binary logs must be retained for at least 3 days; retain them for 7 days to be safe. If DTS cannot read the binary logs, the task fails. In exceptional cases, data inconsistency or loss may occur. Retaining logs for fewer days than required means the Service Level Agreement (SLA) for DTS may not apply. See Modify the retention period.

• Do not write data to the source database during full-only migration (schema migration + full data migration without incremental). Writing to the source during this phase causes data inconsistency. To safely write to the source during migration, include incremental data migration.

• Do not write data from other sources to the destination MaxCompute project during migration. External writes cause data inconsistency.

• MaxCompute does not support primary key constraints. If network errors occur, DTS may write duplicate records to the MaxCompute project.

• DTS retries failed tasks for up to 7 days. Before switching workloads to the destination, stop or release failed tasks. Alternatively, revoke write permissions from the DTS accounts on the destination. If you do not, the source data overwrites destination data when a failed task resumes.

Operational limits

• DTS does not migrate read-only nodes of the source PolarDB for MySQL cluster.

• DTS does not migrate Object Storage Service (OSS) external tables from the source PolarDB for MySQL cluster.

• DTS does not migrate foreign keys. Cascade and delete operations dependent on foreign keys are not replicated to the destination.

• Migrate data during off-peak hours. Full data migration uses read and write resources on both the source and destination, which increases load on both database servers.

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

• If a DTS instance fails, the DTS helpdesk attempts recovery within 8 hours. Recovery may involve restarting the instance or adjusting DTS instance parameters (not database parameters). For parameters that may be modified, see Modify instance parameters.

Step 1: Open the Data Migration page

Use either the DTS console or the DMS console.

Step 2: Configure source and destination databases

1. Click Create Task.

2. Configure the following parameters.

General

Source database

Destination database

1. Click Test Connectivity and Proceed.

Make sure the CIDR blocks of DTS servers are added to the security settings of the source and destination databases. DTS can add them automatically, or you can add them manually. See Add DTS server IP addresses to a whitelist.

1. Click OK to grant DTS permissions on the MaxCompute project. Then click Test Connectivity and Proceed.

Step 3: Configure migration objects

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

Migration types

If you skip Schema Migration, create the destination database and tables manually before starting the task, and enable object name mapping in Selected Objects.

If you skip Incremental Data Migration, do not write to the source database during migration to avoid data inconsistency.

Table configuration

Object selection

Parameter	Description
Source Objects	Select the objects to migrate. Click the icon to move them to Selected Objects. Tables are the supported object type for this migration path.
Selected Objects	To rename a single object in the destination, right-click it in Selected Objects. See Map the name of a single object. To rename multiple objects at once, click Batch Edit. See Map multiple object names at a time. To filter rows in a table, right-click the table and configure filter conditions. See Specify filter conditions. Note Renaming an object with object name mapping may cause dependent objects to fail migration.

1. Click Next: Advanced Settings.

Step 4: Configure advanced settings

Step 5: Run the precheck

1. To preview the API parameters before saving, hover over Next: Save Task Settings and Precheck and click Preview OpenAPI parameters.

2. Click Next: Save Task Settings and Precheck.

DTS runs a precheck before the migration task can start. The task only starts after the precheck passes.

• If a check item fails, click View Details next to it, fix the issue, and click Precheck Again.

• If an alert fires on a check item and the item can be safely ignored, click Confirm Alert Details, then click Ignore in the dialog box and click OK. Then click Precheck Again. Ignoring an alert may cause data inconsistency.

Step 6: Purchase an instance and start the task

1. Wait for Success Rate to reach 100%, then click Next: Purchase Instance.

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

1. Read and accept Data Transmission Service (Pay-as-you-go) Service Terms by selecting the check box.

2. Click Buy and Start, then click OK in the confirmation dialog.

The task appears on the Data Migration page.

• Tasks without incremental migration stop automatically when full migration finishes. The status shows Completed.

• Tasks with incremental migration run continuously. The status shows Running. Stop the task manually when you are ready to cut over.