Migrate data from PolarDB-X 2.0 to PolarDB-X 1.0

Use Data Transmission Service (DTS) to migrate data from a PolarDB-X 2.0 instance to a PolarDB-X 1.0 instance. DTS supports full data migration and incremental data migration, which you can combine to minimize downtime.

Important

This feature is in canary release and is available only to some users.

Choose a migration type

Migration type	When to use	Cost
Full data migration only	Migrating a static dataset; no writes to the source during migration	Task configuration fee: free. Data transfer fee: free, except when the Access Method of the destination database is set to Public IP Address — in that case, you are charged for Internet traffic. See Billable items.
Full + incremental data migration	Keeping the source database live during migration; requires a cutover at the end	Full migration: free (same conditions as above); incremental migration: charged. See Billing overview.

If you use full migration only, stop all writes to the source database before starting the task. Otherwise, the source and destination databases will have inconsistent data.

Prerequisites

Before you begin, ensure that you have:

A destination PolarDB-X 1.0 instance with storage space larger than the amount of data to be migrated. See Create a PolarDB-X 1.0 instance
A database and tables created in the destination instance to receive the migrated data. See Create a database and Execute basic SQL operations
Database accounts with the required permissions on both the source and destination instances (see Permissions required)

Use the same database and table names in the destination instance as in the source. If the names differ, use the object name mapping feature in the Selected Objects section when you configure the task.

Permissions required

Database	Full migration	Incremental migration
Source PolarDB-X 2.0	SELECT	REPLICATION SLAVE, REPLICATION CLIENT, and SELECT on the objects to be migrated
Destination PolarDB-X 1.0	Read and write

To create accounts and grant permissions:

For PolarDB-X 2.0: see Manage database accounts and Account permission issues during data synchronization
For PolarDB-X 1.0: see Manage database accounts

Limitations

Source database

The server hosting the source database must have sufficient outbound bandwidth. Insufficient bandwidth reduces migration speed.
Read-only instances of Enterprise Edition PolarDB-X 2.0 are not supported as the source.
The following objects cannot be migrated:
- Tables with uppercase letters in their names
- TABLEGROUP objects and databases or schemas with the Locality attribute
- Tables whose names are reserved words (for example, select)
- Tables without PRIMARY KEY or UNIQUE constraints, or with non-unique fields — the destination may contain duplicate records
If you rename tables or columns in the destination and are migrating individual tables (not entire databases), the task supports at most 1,000 tables. Exceeding this limit causes a request error. Split the tables across multiple tasks, or migrate entire databases instead.
For incremental migration, binary logging must be enabled (it is on by default in PolarDB-X 2.0) and the binlog_row_image parameter must be set to full. If the parameter is not set to full, the precheck fails and the task cannot start. See Parameter settings.
Do not perform DDL operations that change the database or table schema during full data migration. DTS queries the source database during full migration, which creates metadata locks that may block DDL operations.
If the network configuration of the PolarDB-X 2.0 instance changes, the migration instance may experience a temporary delay.

Other limitations

DTS periodically runs CREATE DATABASE IF NOT EXISTS `test` on the source database to write heartbeat data and advance the binlog offset. If Whether to delete SQL operations on heartbeat tables of forward and reverse tasks is set to Yesalert notification settings (or the source database account lacks CREATE DATABASE permission), and no DML operations run on the source for an extended period, the latency displayed by DTS may be inaccurate. To refresh the latency, run a DML operation on the source database.
Full data migration uses concurrent INSERT operations, which causes table fragmentation in the destination database. After full migration completes, the storage space used by the destination tables is larger than that used by the source tables.
Full data migration consumes read and write resources on both the source and destination databases. Run migration tasks during off-peak hours — for example, when CPU loads on both databases are below 30%.
If data is written to the destination from sources other than DTS during migration, data inconsistency or task failure may occur.
If an instance fails, DTS support will attempt to recover it within 8 hours. Recovery operations may include restarting the instance and adjusting DTS instance parameters (not database parameters). For parameters that may be adjusted, see Modify instance parameters.

SQL operations supported for incremental migration

Operation type	Statements
DML	INSERT, UPDATE, DELETE
DDL	CREATE TABLE, RENAME TABLE, ALTER TABLE, DROP TABLE, TRUNCATE TABLE, CREATE INDEX, DROP INDEX

DDL notes:

Only CREATE TABLE for single tables can be migrated. CREATE TABLE for sharded databases and tables is not supported.
If the source is an Enterprise Edition PolarDB-X 2.0 instance, CREATE INDEX cannot be migrated.
RENAME TABLE may cause data inconsistency if the renamed table is selected as a migration object. To avoid this, select the database (not the individual table) as the migration object, and make sure the databases the table belongs to — both before and after the rename — are included in the migration objects.

Step 1: Go to the Data Migration page

Use one of the following methods:

DTS console

Log on to the DTS console.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

Note

The actual steps may vary based on the DMS console mode and layout. See Simple mode and Customize the layout and style of the DMS console.

Log on to the DMS console.DMS console
In the top navigation bar, go to 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: Create a task

Click Create Task to go to the task configuration page.

Step 3: Configure the source and destination databases

Category	Parameter	Description
(None)	Task Name	DTS generates a name automatically. Specify a descriptive name to make the task easy to identify. The name does not need to be unique.
Source Database	Select Existing Connection	If the instance is registered with DTS, select it from the drop-down list — DTS auto-fills the parameters. Otherwise, configure the parameters manually. In the DMS console, select the instance from Select a DMS database instance.
	Database Type	Select PolarDB-X 2.0.
	Access Method	Select Alibaba Cloud Instance.
	Instance Region	Select the region of the source PolarDB-X 2.0 instance.
	Replicate Data Across Alibaba Cloud Accounts	Select No (this example uses the current account).
	Instance ID	Select the ID of the source PolarDB-X 2.0 instance.
	Database Account	Enter the database account for the source instance. See Permissions required.
	Database Password	Enter the password for the database account.
Destination Database	Select Existing Connection	If the instance is registered with DTS, select it from the drop-down list — DTS auto-fills the parameters. Otherwise, configure the parameters manually. In the DMS console, select the instance from Select a DMS database instance.
	Database Type	Select PolarDB-X 1.0.
	Access Method	Select Alibaba Cloud Instance.
	Instance Region	Select the region of the destination PolarDB-X 1.0 instance.
	Instance ID	Select the ID of the destination PolarDB-X 1.0 instance.
	Database Account	Enter the database account for the destination instance. See Permissions required.
	Database Password	Enter the password for the database account.

Step 4: Test the connection

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. See Add DTS server IP addresses to a whitelist.

Step 5: Configure migration objects

On the Configure Objects page, configure the following settings:

Parameter	Description
Migration Types	Select Full Data Migration to migrate a static dataset. Select both Full Data Migration and Incremental Data Migration to keep the source database live during migration.
Incremental CDC Type	Select a type based on the log engine of the PolarDB-X 2.0 instance. Available only when Incremental Data Migration is selected. Before selecting Multi-stream Change Data Capture (CDC), make sure multi-stream is enabled on the PolarDB-X 2.0 instance. See Enable multi-stream.
Processing Mode of Conflicting Tables	Precheck and Report Errors: the precheck fails if the destination contains tables with the same names as the source. If tables cannot be deleted or renamed, use the object name mapping feature to rename migrated tables. See Map object names. Ignore Errors and Proceed: skips the precheck for identical table names. During full migration, existing records in the destination are retained. During incremental migration, existing records are overwritten. If the source and destination schemas differ, only specific columns are migrated or the task may fail.
Source Objects	Select one or more objects and click the arrow icon to add them to Selected Objects. Select databases or tables as migration objects.
Selected Objects	Right-click an object to rename it in the destination or specify a target object. See Map object names. To remove an object, select it and click the remove icon. Right-click a table to specify WHERE filter conditions (see Specify filter conditions) or to select the SQL operations for incremental migration. Note Renaming an object may cause dependent objects to fail migration.

Click Next: Advanced Settings.

Step 6: Configure advanced settings

Parameter	Description
Dedicated Cluster for Task Scheduling	By default, DTS schedules the task to a shared cluster. For higher stability, purchase a dedicated cluster. See What is a DTS dedicated cluster.
Retry Time for Failed Connections	How long DTS retries failed connections before marking the task as failed. Valid values: 10–1,440 minutes. Default: 720 minutes. Set to at least 30 minutes. If different tasks share the same source or destination database, the value set most recently takes effect. While DTS is retrying, you are charged for the instance.
Retry Time for Other Issues	How long DTS retries failed DDL or DML operations. Valid values: 1–1,440 minutes. Default: 10 minutes. Set to greater than 10 minutes. Must be less than Retry Time for Failed Connections.
Enable Throttling for Full Data Migration	Limits resource usage during full migration. Configure Queries per second (QPS) 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 resource usage 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.
Whether to delete SQL operations on heartbeat tables of forward and reverse tasks	Yes: DTS does not write heartbeat SQL to the source database. Latency information may be inaccurate. No: DTS writes heartbeat SQL. Physical backup and cloning of the source database may be affected.
Environment Tag	(Optional) Select a tag to identify the instance.
Monitoring and Alerting	No: no alerts configured. Yes: configure an alert threshold and notification settings. See Configure monitoring and alerting when you create a DTS task.

Step 7: Configure data verification (optional)

Click Next Step: Data Verification to set up a data verification task. See Configure a data verification task.

Step 8: Run the precheck

Click Next: Save Task Settings and Precheck.

To preview the API parameters for this task first, hover over Next: Save Task Settings and Precheck and click Preview OpenAPI parameters.

The task must pass the precheck before it can start.

If the precheck fails, click View Details next to each failed item, troubleshoot the issue, and click Precheck Again.

If an alert is triggered for an item that can be ignored, click Confirm Alert Details > Ignore > OK, then click Precheck Again. Ignoring alert items may cause data inconsistency.

Step 9: Purchase the instance and start the task

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

On the Purchase Instance page, configure the following:

Section	Parameter	Description
New Instance Class	Resource Group	The resource group for the migration instance. Default: default resource group. See What is Resource Management?
New Instance Class	Instance Class	The instance class determines migration speed. Select based on your requirements. See Instance classes of data migration instances.

Read and agree to Data Transmission Service (Pay-as-you-go) Service Terms by selecting the check box.
Click Buy and Start, then click OK in the confirmation dialog.

View task progress on the Data Migration page.

A full migration-only task stops automatically when complete. The status shows Completed.

A task with incremental migration never stops automatically. The status shows Running.

What's next

After the migration task reaches the desired state, complete the following steps:

Verify data consistency — confirm that the data in the destination PolarDB-X 1.0 instance matches the source. If you configured data verification, check the results in DTS.
Cut over application traffic — update your application's database connection string to point to the destination PolarDB-X 1.0 instance.
Stop the migration task — if the task is running incremental migration, stop it after cutover to avoid unnecessary charges.
Clean up — release the DTS instance once migration is complete to stop billing.