PolarDB:Clone an ApsaraDB RDS for MySQL instance to a PolarDB for MySQL cluster with one click

Usage notes

When you migrate data to a PolarDB cluster by using the one-click cloning feature, incremental data of the source RDS instance is not synchronized to the 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. The PolarDB cluster contains the accounts, databases, IP whitelist, and required parameters of the source RDS instance.

The following list describes the versions and storage types of source ApsaraDB RDS for MySQL instances that support one-click cloning, and the versions of the target PolarDB for MySQL cluster:

• You can clone a source ApsaraDB RDS for MySQL instance 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 all be cloned to PolarDB for MySQL.

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

Comparison between physical migration and logical migration

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

• 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 (DTS data synchronization): This method uses Data Transmission Service (DTS) to create a data synchronization task that synchronizes the schemas and full data of the source ApsaraDB RDS for MySQL instance to the newly created PolarDB for MySQL cluster.

The following table describes the differences between physical migration (physical replication) and logical migration (DTS data synchronization):

The following table describes the ApsaraDB RDS for MySQL versions and storage types that support cloning:

Among these configurations, physical migration (physical replication) is used only when a High-availability Edition ApsaraDB RDS for MySQL 5.6 or 5.7 instance that uses local SSDs is cloned to a same-version PolarDB for MySQL cluster. All other ApsaraDB RDS for MySQL configurations are cloned to a same-version or different-version PolarDB for MySQL cluster by using logical migration (DTS data synchronization).

Benefits

No data is lost during the cloning process.

Prerequisites

• To use physical migration for one-click cloning, the source RDS instance must meet the following version requirements. Logical migration has no version requirements:

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

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

  Note

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

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

• The source RDS instance does not have TDE or SSL enabled. If either feature is enabled, you can manually create a DTS data migration task to migrate the source RDS instance to PolarDB. For more information, see Migrate RDS for MySQL to PolarDB for MySQL.

• If the RDS instance runs in high-security mode (database proxy mode), you must create a privileged account (see Create an account), or switch to high-performance mode (see Upgrade the network connection mode of an ApsaraDB RDS instance) before you can perform one-click cloning. On the Database Connection page in the ApsaraDB RDS console, you can view the activation status of Database Proxy, as well as the internal endpoint (in the format InstanceID.mysql.rds.aliyuncs.com) and port of the current network type, such as the classic network.

Limits

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

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

• Physical migration (physical replication) has the following limits:

  • Cross-region migration is not supported.

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

• Logical migration (DTS data synchronization) has the following limits:

  • Cross-region migration is not supported.

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

  • The source database has the following limits:

    Type

    Description

    Source database limits

    The tables to be synchronized must have a primary key or a unique constraint, and the fields must be unique. Otherwise, duplicate data may appear in the destination database. If the objects to synchronize are tables and you need to edit them (for example, map column names), a single synchronization task supports a maximum of 1,000 tables. If you exceed this limit, a request error is reported after you submit the task. In this case, split the tables to synchronize and configure multiple tasks in batches, or configure a task to synchronize the entire database. Binary logging: You must enable binary logging. For more information about how to enable binary logging, see Modify instance parameters, and binlog_row_image must be set to full. Otherwise, an error is reported during the precheck and the data synchronization task cannot be started.

  • Other limits:

    Type

    Description

    Other limits

    Before you synchronize data, evaluate the performance of the source and destination databases. As a best practice, synchronize data during off-peak hours. Otherwise, the initial full data synchronization occupies read and write resources of the source and destination databases, which may increase the database loads. The initial full data synchronization concurrently performs INSERT operations, which causes fragmentation in the tables of the destination database. Therefore, after the initial full data synchronization is complete, the tablespace of the destination instance is larger than that of the source instance. If the objects to synchronize are one or more tables instead of an entire database, do not use tools such as gh-ost or pt-online-schema-change to perform online DDL operations on the objects to synchronize in the source database during data synchronization. Otherwise, the synchronization fails. You can use Data Management (DMS) to perform online DDL operations. For more information, see Change schemas without locking tables. During DTS synchronization, data from sources other than DTS must not be written to the destination database. Otherwise, the data in the source and destination databases becomes inconsistent. For example, if you use DMS to perform an online DDL operation while data from a source other than DTS is being written to the destination database, data loss may occur in the destination database. By default, DTS disables foreign key constraints when it synchronizes data to the destination database. Therefore, cascade and delete operations in the source database are not synchronized to the destination database.

Billing

• Migrating data from ApsaraDB RDS to a PolarDB cluster is free of charge. You are charged only for purchasing the PolarDB cluster. For more information about the fees of a PolarDB cluster, see Billable items.

• In addition to the fees of purchasing the PolarDB cluster, you are also charged for the synchronization tasks created by DTS. However, this feature is currently in the trial phase, and a created synchronization task is free of charge within 30 days. Accounts such as virtual network operator (VNO) accounts, Jushita accounts, Alibaba Cloud International Site accounts, and RAM users are not eligible for this free trial. The following table describes the details:

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

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

Prechecks (logical migration only)

Step 1: Clone from an RDS instance

This operation creates a PolarDB cluster with 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 Billing Method as Subscription, Pay-As-You-Go, or Serverless.

   • Subscription: You pay for compute node fees when creating the cluster. Storage space is billed by the hour based on actual data volume and deducted from your account hourly.

   • Pay-as-you-go: No prepayment is required. Both compute nodes and storage space (based on actual data volume) are billed by the hour and deducted from your account hourly.

   • Serverless: No prepayment is required. Compute nodes, storage space, database proxy, and other resources dynamically scale based on actual demand during cluster use and are billed based on actual usage.

5. Configure the following parameters.

   Note

   For parameters not described in detail in the table below, see the relevant section in Purchase a cluster.

   Parameter	Description
   Creation Method	Select Clone from RDS.
   Region	Select the region where the source ApsaraDB RDS for MySQL instance resides. Note The new PolarDB cluster is also 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 excluded.
   Database Engine	The database engine version of 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. As a best practice, select a specification that is not lower than that of the source RDS instance. For more information about PolarDB node specifications, see Compute node specifications for 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 (DTS data synchronization) for one-click cloning, click the cluster ID to go to the Basic Information page of the cluster and view the migration status. If the RDS migration status changes to Pre-check failed, follow the instructions in Error Message to resolve the issue.

   For example, if triggers exist in the source RDS, the pre-check will fail with the error "RDS instance has triggers". Delete the triggers from the source RDS first, then click Continue migrating, or click Give up migration and manually create a 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 more information about the impacts, see FAQ.

Step 2: View the details of a data synchronization task (logical migration only)

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

1. Go to the PolarDB console.

2. Find the target cluster and click the cluster ID.

3. On the Basic Information page, in the RDS Migration section, click the task name of 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 the precheck failure details, the synchronization task details, and the synchronization task logs.

   On the task management details page, the Task Progress section displays the execution status of four stages: precheck, schema migration 1, full data migration, and schema migration 2. Click the Check Items tab to view the precheck pass rate and the result of each check item, including the source database connectivity check, the destination database connectivity check, the source database permission check, and the destination database permission check. If all check items are displayed as successful, the precheck is passed.

FAQ

• Q: What is the difference between One-click upgrade of ApsaraDB RDS for MySQL and one-click cloning of ApsaraDB RDS for MySQL to PolarDB for MySQL?

  A: The following table describes the differences:

  Item	One-click upgrade of ApsaraDB RDS for MySQL	One-click cloning of ApsaraDB RDS for MySQL to PolarDB for MySQL
  Whether incremental data migration or synchronization is supported	Supported	Not supported
  Whether operations on the source RDS instance are affected	No impact	No impact
  Whether the source and destination MySQL versions can be different	Can be different	Can be different

• Q: Does cloning from an RDS instance affect the source RDS instance?

  A: Cloning does not affect the normal operation of the source RDS instance. However, the full cloning process consumes some resources of the source instance.

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

  A: Canceling the migration has the following impacts:

  • The synchronization link from the source cluster to the destination cluster is disconnected, and the two clusters are no longer associated.

  • The destination cluster returns to the read/write state and is not automatically released.If you no longer need the cluster, release it as soon as possible to avoid additional charges.

  • When you manually cancel the migration, you can choose whether to disable binary logging (Binlog) for the cluster. When the migration is canceled automatically, Binlog is not disabled.

    Note

    Disabling Binlog slightly improves write performance. After Binlog is disabled, existing Binlog files are retained indefinitely. You can first shorten the retention period of Binlog files, wait until the files that you no longer need are automatically deleted, and then disable Binlog. After you disable Binlog, the cluster automatically restarts. The restart task finishes within 5 minutes, and the service is transiently disconnected for about 40 seconds during the restart. The exact duration depends on the data volume and the number of tables. Perform this operation during off-peak hours and make sure that your application has a reconnection mechanism.

Related API operations