How to one-click clone data from an RDS for MySQL instance to a PolarDB for MySQL cluster - PolarDB

Choose a migration method

One-click cloning supports two methods: physical migration and logical migration (via Data Transmission Service (DTS)). The method applied depends on your source instance's MySQL version, edition, and storage type.

If your source instance is...	Migration method
RDS MySQL 5.6 or 5.7, High-availability Edition, local SSD, cloning to the same MySQL version	Physical migration
Any other combination (MySQL 8.0, cloud disk, different target version, etc.)	Logical migration

Physical migration copies full data directly from the source instance without involving DTS. It is faster and has no impact on source instance operations.

Logical migration creates a DTS data synchronization task to migrate schemas and full data. It supports a wider range of source configurations and allows cross-version cloning, but is subject to DTS-specific limits.

Neither method supports incremental data synchronization or cross-region migration.

Supported versions and storage types

The following table shows which storage types are available per RDS edition and MySQL version. Physical migration applies only to RDS MySQL 5.6 or 5.7, High-availability Edition, local SSD, cloning to the same MySQL version. All other combinations use logical migration.

RDS edition	MySQL 5.6	MySQL 5.7	MySQL 8.0
Basic Edition	N/A	Cloud disk	Cloud disk
High-availability Edition	Local SSD	Local SSD and cloud disk	Local SSD and cloud disk
Cluster Edition	N/A	Cloud disk	Cloud disk
Enterprise Edition	Local SSD	Local SSD	Local SSD

Billing

Physical migration: No charge for data migration. You pay only for the PolarDB cluster. See Billable items overview.
Logical migration: No charge for the DTS synchronization task within the first 30 days after it is created. After 30 days, the task is automatically canceled. This free trial does not apply to virtual network operator (VNO) accounts or Resource Access Management (RAM) users.

Prerequisites

Before you begin, verify that:

The target PolarDB cluster runs the same or a later MySQL version than the source instance. Downgrading is not supported (for example, you cannot clone an RDS MySQL 5.7 instance to a PolarDB for MySQL 5.6 cluster).

For physical migration only:

The source instance meets the minimum minor version: To check the minor version, run the following statement on the source instance:
- RDS MySQL 5.6: minor version 20190815 or later
- RDS MySQL 5.7: minor version 20200331 or later
```
SHOW VARIABLES LIKE '%rds_release_date%';
```
If the minor version is earlier than required, upgrade it before proceeding. See Update the minor engine version.

The table storage engine is InnoDB or X-Engine. To identify tables using other engines, run:

SELECT TABLE_SCHEMA, TABLE_NAME, ENGINE
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_SCHEMA NOT IN ('information_schema', 'mysql', 'performance_schema', 'sys')
  AND ENGINE NOT IN ('InnoDB', 'X-Engine');

Convert any tables returned before cloning.

Transparent Data Encryption (TDE) and SSL are disabled on the source instance. See TDE and SSL. If TDE or SSL is enabled and you cannot disable it, use DTS to manually migrate the data instead. See Migrate data from an ApsaraDB RDS for MySQL instance to a PolarDB for MySQL cluster.
If Database Proxy (Safe Mode) is enabled, either create a privileged account or switch the network connection mode to high-performance mode. See Create an account and Upgrade the network connection mode of an ApsaraDB RDS instance.

For logical migration only:

Complete both prechecks below before starting the migration.

Precheck 1: Verify the service-linked role

The logical migration method requires the AliyunServiceRoleForPolarDB service-linked role to exist in your account. If it does not exist, create it before proceeding.

Log on to the Resource Access Management (RAM) console and open the Roles page.
Check whether AliyunServiceRoleForPolarDB appears in the list. If the role exists, skip to Precheck 2.
Click Create Role. In the Select Role Type step, select Alibaba Cloud Service and click Next.
In the Configure Role step, set Role Type to Service Linked Role and select ApsaraDB for PolarDB from the Select Service list.
Click OK and confirm that the role now appears in the list.

Precheck 2: Remove redundant system accounts from the source instance

Each RDS MySQL version has a designated system account. If both root and aliyun_root exist simultaneously, the destination PolarDB cluster's system accounts may be overwritten during cloning. Remove any extra system accounts before starting.

RDS MySQL version	Correct system account
RDS MySQL 5.6	`root`
RDS MySQL 5.7	`aliyun_root`
RDS MySQL 8.0	`aliyun_root`

Extra system accounts may have been created manually or inherited from a previous version upgrade. Some accounts may not be visible in the console.

Example: removing a redundant account from RDS MySQL 5.6

The correct account for MySQL 5.6 is root. If aliyun_root also exists, remove it.

Connect to the database with a privileged account.

Check which system accounts exist:

SELECT * FROM mysql.user WHERE `user` IN ('root', 'aliyun_root');

Remove the redundant account. Confirm it is not used in your workload before proceeding.
```
DELETE FROM mysql.user WHERE `user` = 'aliyun_root' LIMIT n;
```

Logical migration source instance limits:

Tables must have a PRIMARY KEY or UNIQUE constraint, with all fields unique. Tables without these constraints may result in duplicate data in the destination cluster.
If you select individual tables (not the entire database) as sync objects and need to rename tables or columns, a single task supports up to 1,000 tables. For more than 1,000 tables, use multiple tasks or sync the entire database.
Binary logging must be enabled, and binlog_row_image must be set to full. See Modify instance parameters.
Schedule migration during off-peak hours. The initial full data synchronization uses read and write resources on both source and destination, which may increase database load.
After full data synchronization completes, the destination tablespace may be larger than the source due to fragmentation from concurrent INSERT operations.
Do not use gh-ost or pt-online-schema-change for DDL operations on synced tables during synchronization. Use Data Management (DMS) for online DDL if needed.
DTS disables FOREIGN KEY constraints on the destination by default. Cascade and delete operations from the source are not replicated.
Write data to the destination only through DTS during synchronization. Writing from other sources may cause data inconsistency or loss.

Step 1: Create the cluster by cloning

Log on to the PolarDB console.
In the upper-left corner, select the region where the source RDS instance is deployed.
Click Create Cluster.

Set Billing Method to Subscription, Pay-as-you-go, or Serverless.

Billing method	How it works
Subscription	Pay upfront for compute nodes. Storage is billed hourly based on actual usage.
Pay-as-you-go	No upfront payment. Compute nodes and storage are billed hourly based on actual usage.
Serverless	No upfront payment. Compute nodes, storage, and PolarProxy scale automatically. Billed based on actual resource usage.

Configure the following parameters. For parameters not listed here, see Purchase clusters.

Parameter	Description
Creation Method	Select Clone from RDS.
Region	The region where the source RDS instance is deployed. The destination PolarDB cluster must be in the same region.
Source RDS Version	The MySQL version of the source RDS instance: 5.6, 5.7, or 8.0.
Source RDS Instance	The source RDS instance. Read-only instances are not listed.
Database Engine	The MySQL version for the destination PolarDB cluster. Can be the same as or different from the source.
Node Specification	The compute node specifications. Select specifications equal to or higher than the source instance. See Compute node specifications of PolarDB for MySQL Enterprise Edition.

Review the cluster configuration in the upper-right corner. For Subscription clusters, set Duration, Quantity, and Auto-renewal.
Read and accept the terms of service, then click Confirm Order.
On the Purchase page, confirm the order and payment method, then click Purchase.
Wait 10 to 15 minutes, then check the Clusters page for the new cluster. The cluster is ready when its status changes from Creating to Running. Make sure you have selected the correct region.

Step 2: Verify migration status

After the cluster is created, verify that the migration completed successfully.

Log on to the PolarDB console and go to the Clusters page.
Click the new cluster's ID to open its Basic Information page.
Check the RDS Migration section: Example: If the source instance has a trigger, the precheck fails with "The RDS instance has a trigger." Delete the trigger and click Continue Migration, or see Configure a data synchronization task for a source database that contains a trigger.
- If the status is Running, the migration is proceeding normally.
- If the status is Precheck Failed, follow the error message to fix the issue, then click Continue Migration. Alternatively, click Cancel Migration and manually create a DTS synchronization task.

Step 3: View DTS task details (logical migration only)

If logical migration is used and you need to investigate errors (such as precheck failures or high replication latency), view the DTS task details.

Log on to the PolarDB console and click the cluster ID.
On the Basic Information page, find the RDS Migration section and click DTS Data Synchronization Task.
In the DTS console, find the data synchronization task. From this page, you can view precheck failure details, task status, and task logs.

FAQ

What is the difference between cloning and upgrading an RDS instance to PolarDB?

	Upgrade RDS to PolarDB	Clone RDS to PolarDB
Incremental data synchronization	Yes	No
Source instance affected	No	No
Cross-version migration	Yes	Yes

Cloning creates an independent copy of the source data without keeping the source instance in sync. Upgrading keeps the source and destination in sync during migration so you can cut over with minimal data loss.

Does cloning affect the source RDS instance?

No. Cloning does not interrupt the source instance but does consume some of its resources during the process.

What happens when I cancel the migration?

Canceling the migration has the following effects:

The synchronization link between the source instance and the destination cluster is disconnected.
The destination cluster becomes readable and writable but is not automatically released. Release the cluster if you no longer need it to avoid ongoing charges.
You can choose whether to disable binary logging on the cluster when canceling manually. Binary logging is not disabled when the migration is automatically canceled.

Disabling binary logging slightly improves write performance. After you disable it, existing binary logs are retained. To delete them, reduce the retention period and wait for the logs to be automatically deleted, then disable binary logging. The cluster restarts automatically after binary logging is disabled. The restart completes within 5 minutes, with approximately 40 seconds of service interruption. The exact duration depends on the amount of data and the number of tables. Disable binary logging during off-peak hours and make sure your application can automatically reconnect.

API reference

API	Operation
CreateDBCluster	Creates a PolarDB cluster. To clone from an RDS instance, set `CreationOption` to `CloneFromRDS`.

What's next

Update your application's database connection endpoint to the PolarDB cluster endpoint. See Manage the endpoints of a cluster.