PolarDB:Clone an ApsaraDB RDS for MySQL instance to PolarDB for MySQL

Important notes

When you clone data to a PolarDB cluster by using the one-click cloning feature, the feature does not synchronize incremental data from the source RDS instance to the target PolarDB cluster.

Overview

PolarDB supports one-click cloning of data from an ApsaraDB RDS for MySQL instance to a new PolarDB for MySQL cluster. The one-click cloning feature creates a new PolarDB cluster with the same data as the source RDS instance, and the PolarDB cluster contains the accounts, databases, IP whitelist, and necessary parameters from the source RDS instance.

The following list describes the supported versions and storage types for the source ApsaraDB RDS for MySQL instance and the target PolarDB for MySQL cluster:

• You can clone source ApsaraDB RDS for MySQL instances of all versions and all storage types. ApsaraDB RDS for MySQL 5.6, 5.7, and 8.0 instances that use local SSDs or cloud disks can be cloned to a PolarDB for MySQL cluster.

• You can clone an ApsaraDB RDS for MySQL instance to a PolarDB for MySQL cluster of the same or a different version. For example, you can clone an ApsaraDB RDS for MySQL 5.6 instance to a PolarDB for MySQL 5.6 cluster, or to a PolarDB for MySQL 8.0 cluster.

Comparison of physical and logical migration

The one-click cloning feature supports two methods: physical migration (physical replication) and logical migration (data synchronization using DTS).

• Physical migration (physical replication): This method uses physical replication to copy all data from the source ApsaraDB RDS for MySQL instance to the newly created PolarDB for MySQL cluster.

• Logical migration (data synchronization using DTS): This method uses Data Transmission Service (DTS) to create a data synchronization task. The task synchronizes the schema and full data from the source ApsaraDB RDS for MySQL instance to the newly created PolarDB for MySQL cluster.

The following table compares the physical migration and logical migration methods.

The following table describes the ApsaraDB RDS for MySQL versions and storage types that can be cloned.

Use physical migration only when you clone a High-availability Edition ApsaraDB RDS for MySQL 5.6 or 5.7 instance that uses a local SSD to a PolarDB for MySQL cluster of the same version. For all other configurations, logical migration is used to clone an ApsaraDB RDS for MySQL cluster to a PolarDB for MySQL cluster of the same or a different version.

Benefits

The cloning process causes no data loss.

Prerequisites

• For physical migration, the source RDS instance must meet the following minor version requirements. Logical migration has no version limitations.

  • For ApsaraDB RDS for MySQL 5.6, the minor version must be 20190815 or later.

  • For ApsaraDB RDS for MySQL 5.7, the minor version must be 20200331 or later.

  Note

  You can run the SHOW VARIABLES LIKE '%rds_release_date%'; command to check the minor version of the source RDS instance. If the minor version is earlier than required, you can upgrade it to the latest version. For more information, see Upgrade the minor engine version.

• The one-click cloning feature is supported only for source RDS instances that use the InnoDB or X-Engine storage engine.

• TDE and SSL are not enabled on the source RDS instance. If either feature is enabled, you can manually create a Data Transmission Service (DTS) data migration task to migrate the source RDS instance to PolarDB. For more information, see Migrate ApsaraDB RDS for MySQL to PolarDB for MySQL.

• If your RDS instance runs in High-Security Mode (with Database Proxy enabled), you must create a privileged account (see Create an account) or switch to High-Performance Mode (see [Product/Feature Change] RDS Network Link Upgrade Notice) to perform one-click cloning. On the Database Connection page in the ApsaraDB RDS console, you can view the status of the Database Proxy, as well as the internal endpoint (in the format InstanceID.mysql.rds.aliyuncs.com) and port for the current network type, such as classic network.

Limitations

• You can only clone an ApsaraDB RDS for MySQL instance to a PolarDB for MySQL cluster of the same or a later version. Downgrading is not supported.

  For example, you cannot clone an ApsaraDB RDS for MySQL 5.7 instance to a PolarDB for MySQL 5.6 cluster, or an ApsaraDB RDS for MySQL 8.0.2 instance to a PolarDB for MySQL 8.0.1 cluster.

• Physical migration has the following limitations:

  • Cross-region migration is not supported.

  • You cannot change the parameters of the source RDS instance during the migration.

• Logical migration has the following limitations:

  • Cross-region migration is not supported.

  • You cannot change the parameters of the source RDS instance during the migration.

  • The source database has the following limitations:

    Type

    Description

    Source database limitations

    Tables that you synchronize must have a primary key or a unique constraint, and all fields in the constraint must be unique. Otherwise, duplicate data may exist in the destination database. When synchronizing at the table level and editing objects (such as mapping column names), a single task supports up to 1,000 tables. If you exceed this limit, an error is reported when you submit the task. In this case, we recommend splitting the tables into multiple tasks or configuring a task to synchronize the entire database. Binlog must be enabled, and the binlog_row_image parameter must be set to FULL. For more information about how to enable Binlog, see Modify instance parameters. Otherwise, the precheck will fail, and the data synchronization task cannot start.

  • Other limitations:

    Type

    Description

    Other limitations

    Before you synchronize data, evaluate the performance of the source and destination databases. We recommend performing data synchronization during off-peak hours. The initial full data synchronization consumes read and write resources on both databases, which may increase their loads. The initial full data synchronization performs concurrent INSERT operations, which can cause fragmentation in the destination database tables. As a result, the table space in the destination instance will be larger than in the source instance after synchronization. If you are synchronizing individual tables instead of the entire database, do not perform online DDL changes on the source tables by using tools like gh-ost or pt-online-schema-change during data synchronization. Doing so will cause the synchronization to fail. You can use Data Management Service (DMS) to perform online DDL changes. For more information, see Change schemas without locking tables. During DTS synchronization, do not write data to the destination database from any source other than DTS. This can cause data inconsistencies. For example, if you use DMS to perform an online DDL change while another source is writing to the destination database, data loss may occur. By default, DTS disables foreign key constraints when synchronizing to the destination database. Therefore, cascade and delete operations from the source database are not synchronized.

Billing

• The migration from ApsaraDB RDS to PolarDB is free of charge. You are charged only for the new PolarDB cluster. For more information about PolarDB cluster pricing, see Billable items.

• You are charged for the PolarDB cluster and the DTS data synchronization task. However, the task is free for the first 30 days as part of a trial. This free trial is not available to virtual network operator (VNO) accounts, Jushita accounts, Alibaba Cloud International Site accounts, or RAM users (sub-accounts). The following table describes the details.

  Migration object	Fee
  Schema and full data synchronization	You are not charged for the synchronization task for 30 days after creation. After 30 days, the synchronization task is automatically canceled. Note You can go to the Data Synchronization Tasks page of the new DTS console to view the remaining time for the synchronization task.

The following sections describe how to clone an ApsaraDB RDS for MySQL instance to a PolarDB for MySQL cluster.

Prechecks (logical migration only)

Step 1: Clone from an RDS instance

This step creates a PolarDB cluster that has the same data as the source RDS instance.

1. Log in to the PolarDB console。

2. In the upper-left corner, select the region where the cluster is deployed.

3. Click Create Cluster.

4. Select a billing method: Subscription, Pay-As-You-Go, or Serverless.

   • Subscription: You pay for the compute nodes when you create the cluster. Storage is billed on an hourly basis based on the actual volume of your data, and the fees are deducted from your account balance every hour.

   • Pay-As-You-Go: No upfront payment is required. Both the compute nodes and the storage (based on the actual volume of your data) are billed on an hourly basis, and the fees are deducted from your account balance every hour.

   • Serverless: No upfront payment is required. Resources such as compute nodes, storage, and database proxies are dynamically scaled based on actual workload requirements while the cluster is in use, and you are charged based on the actual amount of resources used.

5. Configure the following parameters.

   Note

   For information about the parameters that are not described in the following table, see the topics about Purchase a cluster.

   Parameter	Description
   Creation Method	Select Clone from RDS.
   Region	Select the region where the source ApsaraDB RDS for MySQL instance is located. Note The new PolarDB cluster will also be created in this region.
   Source RDS Version	The version of the source RDS instance. You can select 5.6, 5.7, or 8.0.
   Source RDS Instance	Select the source RDS instance. Read-only instances are not listed.
   Database Engine	The database engine version for the destination PolarDB cluster. You can select the same version as the source RDS instance or a different version.
   Node Specifications	Select a specification based on your business needs. We recommend selecting a specification that is equal to or higher than the source RDS instance specification. For more information about PolarDB node specifications, see Compute node specifications of Enterprise Edition.

6. In the upper-right corner, review the cluster configuration. Set Subscription Duration (for Subscription clusters), Quantity, and whether to enable Auto-renewal.

7. Read and accept the Service Agreement. Click Buy Now.

8. On the Payment page, confirm the unpaid order details and payment method, then click Place Order .

   Note

   • After successful payment, cluster creation takes 10–15 minutes. You can then see the new cluster in the Cluster List .

   • If cluster nodes show Creating , the cluster is not ready. Only when the cluster status is Running can you use it.

   • Ensure you selected the correct region. Otherwise, you won't see your cluster.

   • If the precheck fails, the destination cluster remains in the Creating state and the upgrade cannot proceed automatically. Resolve the precheck failure based on the error message, and then click Continue Upgrade to proceed. In this case, cluster creation may take longer than 15 minutes, which is expected.

9. Log on to the PolarDB console and view the status of the new PolarDB cluster.

   Note

   If you use logical migration, click the cluster ID to go to the Basic Information page and check the migration status. If the RDS Migration status changes to Pre-check failed, follow the instructions in the Error Message section to resolve the issue.

   For example, if triggers have been created in the source RDS instance, the precheck fails with the error message "Triggers exist in the RDS instance." In this case, delete the triggers from the source RDS instance and then click Continue Migration. Alternatively, click Cancel Migration and manually create a data migration task in the DTS console. For more information, see [Configure tasks for source databases with triggers].

   You can also select Give up migration at this step. For information about the impacts, see FAQ.

Step 2: View data synchronization details (logical migration only)

If you use logical migration, click the cluster ID to go to the Basic Information page and check the migration status. If a migration error (such as a precheck failure) or another exception (such as high replication latency) occurs, you can go to the details page of the corresponding DTS data synchronization task to view specific information.

1. Go to the PolarDB console.

2. Find the target cluster and click its ID.

3. On the Basic Information page, in the RDS Migration section, click the task name under DTS Data Synchronization Task to go to the data synchronization list in the DTS console.

4. Find the corresponding data synchronization task. You can view precheck failure details, task details, and task logs.

   On the task details page, the Task Progress section displays the execution status of four stages: precheck, schema migration 1, full migration, and schema migration 2. Click the Check Items tab to view the precheck success rate and the results of each check item, including source and destination database connectivity and permission checks. The precheck is successful if all check items pass.

FAQ

• Q: What is the difference between upgrading an ApsaraDB RDS for MySQL instance and one-click cloning an ApsaraDB RDS for MySQL instance to a PolarDB for MySQL cluster?

  A: The following table describes the differences.

  Item	One-click upgrade	One-click clone ApsaraDB RDS for MySQL to PolarDB for MySQL
  Incremental data migration	Supported	Not supported
  Impact on source RDS operations	No impact	No impact
  Cross-version migration	Supported	Supported

• Q: What are the impacts of canceling a migration?

  A: Canceling a migration has the following impacts:

  • The synchronization link between the source cluster and the destination cluster is disconnected, and the two clusters are no longer associated with each other.

  • The destination cluster becomes readable and writable and is not automatically released. If you no longer need the cluster, release it as soon as possible to avoid additional costs.

  • When you manually cancel a migration, you can choose whether to disable binlogs for the cluster. If the migration is automatically canceled, binlogs are not disabled. Disabling binlogs slightly improves write performance. After binlogs are disabled, existing binlog files are permanently retained. You can shorten the retention period of binlog files first, wait for the unneeded files to be automatically deleted, and then disable binlogs.

    Note

    After binlogs are disabled, the cluster automatically restarts. The restart is complete within 5 minutes, and the service is interrupted for approximately 40 seconds during the restart. The actual duration varies based on the volume of data and the number of tables. We recommend that you perform this operation during off-peak hours and make sure that your applications can automatically reconnect.

API reference