Use Data Transmission Service (DTS) to migrate data from a PolarDB-X 1.0 instance to a PolarDB-X 2.0 instance. DTS supports schema migration, full data migration, and incremental data migration. Combining all three types keeps your applications running during migration without service interruption.
Prerequisites
Before you begin, ensure that you have:
A PolarDB-X 1.0 source instance with a storage type of ApsaraDB RDS for MySQL (custom or purchased). PolarDB for MySQL is not supported as the storage type
A PolarDB-X 1.0 instance at version 5.2 or later
A destination PolarDB-X 2.0 instance with a database created to receive data. See Create an instance and Create a database
Available storage space on the destination instance larger than the total data size of the source instance
Binary logging configured on the ApsaraDB RDS for MySQL instances attached to the source PolarDB-X 1.0 instance. See Binary logging requirements
Limitations
Source database requirements
Table requirements
Tables to be migrated must have PRIMARY KEY or UNIQUE constraints, with all fields unique. Without this, the destination may contain duplicate records.
DTS does not support schema migration for tables that have only UNIQUE constraints. Create PRIMARY KEY constraints on those tables before starting the migration.
Up to 1,000 tables can be migrated in a single task when you select individual tables as the migration objects and rename tables or columns. To migrate more than 1,000 tables, split them across multiple tasks or migrate entire databases instead.
Binary logging requirements
Binary logging must be enabled on the ApsaraDB RDS for MySQL instances attached to your PolarDB-X 1.0 source. Verify the following parameters. See View the parameters of an instance.
| Parameter | Required value | Notes |
|---|---|---|
| Binary logging | Enabled | If not enabled, the precheck fails and the migration task cannot start. |
binlog_row_image | full | If not set to full, the precheck fails and the migration task cannot start. |
| Binary log retention (incremental migration only) | More than 24 hours | Set this before starting incremental-only migration. |
| Binary log retention (full + incremental migration) | At least 7 days | DTS may fail to obtain binary logs and the task may fail if retention is shorter. After full migration completes, you can reduce this to more than 24 hours. |
Restricted operations during migration
Avoid the following while a migration task is running:
Scaling the capacity of the source instance
Migrating frequently accessed tables or changing shards
Performing DDL operations (these can cause the migration task to fail or result in data inconsistency)
Switching the network type of the source PolarDB-X 1.0 instance (if you must switch, update the migration connection settings afterward)
Writing data to the source database during full-only migration (use schema migration + full data migration + incremental data migration to maintain data consistency)
Things to consider
Data distribution: When DTS migrates data from a PolarDB-X 1.0 instance, data is distributed across the attached ApsaraDB RDS for MySQL instances. DTS runs a subtask for each instance. Monitor subtask status on the Performance Monitoring page.
Foreign keys: During schema migration, DTS migrates foreign keys from source to destination. During full and incremental migration, DTS temporarily disables constraint checks and cascade operations on foreign keys at the session level. Cascade update and delete operations on the source during migration may cause data inconsistency.
XA transactions: DTS ensures data consistency for incremental migration based on the continuity of XA transactions in PolarDB-X 1.0. If XA transaction continuity is disrupted (for example, in disaster recovery scenarios), uncommitted XA transactions may be lost, resulting in data inconsistency.
FLOAT and DOUBLE precision: DTS uses the
ROUND(COLUMN, PRECISION)function for FLOAT and DOUBLE columns. If no precision is specified, DTS defaults to 38 digits for FLOAT and 308 digits for DOUBLE. Verify that these defaults meet your requirements.Tablespace fragmentation: Concurrent INSERT operations during full migration cause table fragmentation in the destination. After full migration, the used tablespace of the destination is larger than that of the source.
Performance impact: Full data migration uses read and write resources on both source and destination databases. Run migrations during off-peak hours to reduce load on database servers.
Task resumption: DTS automatically tries to resume failed migration tasks for up to 7 days. Before switching workloads to the destination, stop or release the migration task, or revoke write permissions from the DTS accounts on the destination database. Otherwise, resumed tasks may overwrite destination data with source data.
Task failure recovery: If a DTS task fails, DTS support will try to restore it within 8 hours. The task may be restarted and task parameters (not database parameters) may be modified during restoration.
Billing
| Migration type | Instance fee | Internet traffic fee |
|---|---|---|
| Schema migration and full data migration | Free | Charged when Access Method is set to Public IP Address. See Billing overview. |
| Incremental data migration | Charged. See Billing overview. | — |
Migration types
| Type | What DTS migrates |
|---|---|
| Schema migration | Schemas of selected objects from source to destination |
| Full data migration | Historical data of selected objects from source to destination |
| Incremental data migration | Data changes after full migration completes, without interrupting source application services |
SQL operations supported during incremental data migration
| Operation type | Supported statements |
|---|---|
| DML | INSERT, UPDATE, DELETE |
Required permissions
| Database | Schema migration | Full data migration | Incremental data migration | How to grant |
|---|---|---|---|---|
| PolarDB-X 1.0 | SELECT | SELECT | SELECT, REPLICATION SLAVE, REPLICATION CLIENT (DTS grants these automatically) | Manage accounts |
| PolarDB-X 2.0 | Read/Write | Read/Write | Read/Write | — |
Create a migration task
Step 1: Go to the Data Migration page
Use either the DTS console or the DMS console.
DTS console
Log on to the DTS console.
In the left-side navigation pane, click Data Migration.
In the upper-left corner, select the region where the migration instance resides.
DMS console
The steps may vary based on your DMS console mode and layout. See Simple mode and Customize the layout and style of the DMS console.
Log on to the DMS console.
In the top navigation bar, move the pointer over Data + AI > DTS (DTS) > Data Migration.
From the drop-down list to the right of Data Migration Tasks, select the region where the migration instance resides.
Step 2: Configure source and destination databases
Click Create Task, then configure the following parameters.
| Section | Parameter | Value |
|---|---|---|
| — | Task Name | Enter a descriptive name. DTS generates one automatically; it does not need to be unique. |
| Source Database | Database Type | PolarDB-X 1.0 |
| Access Method | Alibaba Cloud Instance | |
| Instance Region | Region of the source PolarDB-X 1.0 instance | |
| Replicate Data Across Alibaba Cloud Accounts | No (same account migration) | |
| Instance ID | ID of the source PolarDB-X 1.0 instance | |
| Database Account | Account for the source PolarDB-X 1.0 instance | |
| Database Password | Password for the source account | |
| Destination Database | Database Type | PolarDB-X 2.0 |
| Access Method | Alibaba Cloud Instance | |
| Instance Region | Region of the destination PolarDB-X 2.0 instance | |
| Instance ID | ID of the destination PolarDB-X 2.0 instance | |
| Database Account | Account for the destination PolarDB-X 2.0 instance | |
| Database Password | Password for the destination account |
Click Test Connectivity and Proceed.
Make sure DTS server CIDR blocks are added to the security settings of both source and destination databases. See Add the CIDR blocks of DTS servers.
Step 3: Select objects to migrate
On the Configure Objects page, configure the following parameters.
| Parameter | Description |
|---|---|
| Synchronization Types | Select the migration types to run: <br>• Schema Migration + Full Data Migration: full migration without service continuity <br>• Schema Migration + Full Data Migration + Incremental Data Migration: keeps services running during migration (recommended) <br><br> Note If you skip Schema Migration, create the target database and tables manually and enable object name mapping in Selected Objects. If you skip Incremental Data Migration, do not write to the source database during migration. |
| Processing Mode of Conflicting Tables | • Precheck and Report Errors: fails the precheck if source and destination have tables with identical names. Use object name mapping to rename conflicting tables if they cannot be deleted or renamed in the destination. <br>• Ignore Errors and Proceed: skips the precheck for identical table names. <br><br> Warning Selecting Ignore Errors and Proceed may cause data inconsistency. During full migration, DTS skips records with duplicate primary keys (retaining the existing destination record). During incremental migration, DTS overwrites them. If schemas differ, only some columns may be migrated or the task may fail. |
| Capitalization of Object Names in Destination Instance | Controls capitalization of database, table, and column names in the destination. Default: DTS default policy. See Specify the capitalization of object names. |
| Source Objects | Select objects to migrate, then click the arrow icon to add them to Selected Objects. <br><br> Note Select individual tables rather than entire databases. When you migrate an entire database, DTS does not replicate CREATE TABLE or DROP TABLE changes to the destination. |
| Selected Objects | Right-click a single object to rename it, or click Batch Edit to rename multiple objects at once. See Map object names. <br><br> Note Renaming an object may cause dependent objects to fail migration. |
Step 4: Configure advanced settings
Click Next: Advanced Settings, then configure the following parameters.
| Parameter | Description |
|---|---|
| Dedicated Cluster for Task Scheduling | By default, DTS schedules the task to the shared cluster. Purchase a dedicated cluster to improve migration stability. See What is a DTS dedicated cluster. |
| Retry Time for Failed Connections | How long DTS retries after a connection failure. Valid values: 10–1,440 minutes. Default: 720 minutes. Set this to at least 30 minutes. If DTS reconnects within this window, migration resumes; otherwise the task fails. <br><br> Note If multiple tasks share the same source or destination, the most recently set retry time takes precedence. DTS charges for the instance during retries. |
| Retry Time for Other Issues | How long DTS retries after DDL or DML operation failures. Valid values: 1–1,440 minutes. Default: 10 minutes. Set this to at least 10 minutes. This value must be smaller than Retry Time for Failed Connections. |
| Enable Throttling for Full Data Migration | Limits read and write load during full migration. Configure QPS (Queries per second) to the source database, RPS of Full Data Migration, and Data migration speed for full migration (MB/s). Available only when Full Data Migration is selected. |
| Enable Throttling for Incremental Data Migration | Limits load during incremental migration. Configure RPS of Incremental Data Migration and Data migration speed for incremental migration (MB/s). Available only when Incremental Data Migration is selected. |
| Environment Tag | Optional tag to identify the migration instance. |
| Configure ETL | Enables the extract, transform, and load (ETL) feature. Select Yes to enter data processing statements. See Configure ETL in a data migration or data synchronization task and What is ETL?. |
| Monitoring and Alerting | Select Yes to receive alerts when the task fails or migration latency exceeds a threshold. Configure the alert threshold and notification settings. See Configure monitoring and alerting. |
Step 5: Run the precheck
Click Next: Save Task Settings and Precheck.
To preview the API parameters for this configuration, hover over the button and click Preview OpenAPI parameters before proceeding.
DTS runs a precheck before starting migration. The task starts only after the precheck passes.
If any precheck item fails, click View Details next to that item. Fix the issue, then click Precheck Again.
If a precheck item triggers an alert that can be ignored, click Confirm Alert Details. In the dialog, click Ignore > OK, then click Precheck Again. Ignoring alerts may cause data inconsistency.
Step 6: Purchase an instance and start migration
Wait until Success Rate reaches 100%, then click Next: Purchase Instance.
On the Purchase Instance page, configure the following parameters.
Section Parameter Description New Instance Class Resource Group Resource group for the migration instance. Default: default resource group. See What is Resource Management?. Instance Class Determines migration speed. Select based on your requirements. See Instance classes of data migration instances. Read and accept the Data Transmission Service (Pay-as-you-go) Service Terms.
Click Buy and Start, then click OK.
Verify migration status
After the task starts, view its progress on the Data Migration page.
| Migration type | Expected status |
|---|---|
| Schema migration + full data migration only | Completed — task stops automatically when finished. |
| Includes incremental data migration | Running — incremental migration runs continuously and does not stop automatically. |
What's next
Before switching your applications to the destination PolarDB-X 2.0 instance:
Stop or release the migration task to prevent it from resuming and overwriting destination data. Alternatively, revoke write permissions from the DTS accounts on the destination database.