PolarDB:Create a PolarDB for MySQL cluster by cloning an ApsaraDB RDS for MySQL instance

Precautions

If you migrate data to a PolarDB for MySQL cluster by using one-click cloning, the incremental data of the source ApsaraDB RDS for MySQL instance is not synchronized to the PolarDB for MySQL cluster.

Background information

PolarDB for MySQL allows you to create a PolarDB for MySQL cluster by using the Clone from RDS method. You can use the Clone from RDS method to create a PolarDB for MySQL cluster that has the same data as the source ApsaraDB RDS instance. The created PolarDB for MySQL cluster retains the accounts, databases, IP whitelist, and required parameters of the source RDS instance.

Source ApsaraDB RDS for MySQL instances and destination PolarDB for MySQL clusters must meet the following requirements:

• Source ApsaraDB RDS for MySQL instances that run all MySQL versions and that use all storage types can be cloned. You can clone instances that run MySQL 5.6, 5.7, and 8.0 and that use local SSDs and cloud disks to PolarDB for MySQL clusters with one click.
• ApsaraDB RDS for MySQL instances can be clone to PolarDB for MySQL clusters that run the same or different MySQL versions with one click. 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 between physical migration and logical migration

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

• Physical migration: You can use the physical replication method to copy full data from the source ApsaraDB RDS for MySQL instance to the destination PolarDB for MySQL cluster.
• Logical migration: You can create a data synchronization task on Data Transmission Service (DTS) to migrate the schemas and full data of the source ApsaraDB RDS for MySQL instance to the destination PolarDB for MySQL cluster.

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

Benefits

• The cloning is free of charge.
• No data loss occurs during the cloning.

Prerequisites

• When physical migration is used, the source ApsaraDB RDS instance must meet the following requirements. Logical migration is not subject to these requirements.
  • For ApsaraDB RDS for MySQL 5.6, the minor version of the instance must be 20190815 or later.
  • For ApsaraDB RDS for MySQL 5.7, the minor version of the instance must be 20200331 or later.
  Note You can execute the SHOW VARIABLES LIKE '%rds_release_date%'; statement to view the minor version of the source ApsaraDB RDS instance. If the minor version is earlier than the required version, you can upgrade the minor version to the latest version. For more information, see Update the minor engine version of an ApsaraDB RDS for MySQL instance.
• Transparent Data Encryption (TDE) and SSL are disabled on the source ApsaraDB RDS for MySQL instance. For more information, see TDE and SSL. If TDE or SSL is enabled, you can manually create a data synchronization task on DTS to migrate the source instance to the destination PolarDB for MySQL cluster. For more information, see Migrate data from an ApsaraDB RDS for MySQL instance to a PolarDB for MySQL cluster.
• The table storage engine for the source ApsaraDB RDS for MySQL instance is InnoDB.
• If Database Proxy (Safe Mode) is enabled for the RDS instance, a privileged account is created or the network connection mode of the RDS instance is switched to the high-performance mode. For more information see Create an account and [Important] RDS network link upgrade.

Limits

• The physical migration method is subject to the following limits:
  • Cross-region data migration is not supported.
  • You cannot set the parameters of the source ApsaraDB RDS for MySQL instance during data migration.
• The logical migration method is subject to the following limits:
  • Cross-region data migration is not supported.
  • You cannot set the parameters of the source ApsaraDB RDS for MySQL instance during data migration.
  • Source ApsaraDB RDS for MySQL instances are subject the limits listed in the following table.

    Item

    Description

    Limits on the source database

    The tables to be synchronized must have PRIMARY KEY or UNIQUE constraints and all fields must be unique. Otherwise, the destination database may contain duplicate data records. If you select tables as the objects to be synchronized and you need to edit tables (such as renaming tables or columns) in the destination database, up to 1,000 tables can be synchronized in a single data synchronization task. If you run a task to synchronize more than 1,000 tables, a request error occurs. In this case, we recommend that you split the tables, configure multiple tasks to synchronize the tables, or configure a task to synchronize the entire database. The binary logging feature must be enabled. For more information about how to enable binary logging, see Modify the parameters of an ApsaraDB RDS for MySQL instance. In addition, the binlog_row_image parameter must be set to full. Otherwise, error messages are returned during precheck, and the data synchronization task cannot be started.

  • The following limits also apply:

    Item

    Description

    Other limits

    To ensure compatibility, the version of the destination database must be the same as or later than that of the source database. If the version of the destination database is earlier than that of the source database, database compatibility issues may occur. Before you synchronize data, evaluate the impact of data synchronization on the performance of the source and destination databases. We recommend that you synchronize data during off-peak hours. During initial full data synchronization, DTS uses read and write resources of the source and destination databases. This may increase the loads on the database servers. During full data synchronization, concurrent INSERT operations cause fragmentation in the tables of the destination database. After full data synchronization is complete, the tablespace of the destination database is larger than that of the source database. If you select one or more tables instead of an entire database as the objects to synchronize, do not use gh-ost or pt-online-schema-change to perform DDL operations on the tables during data synchronization. Otherwise, data may fail to be synchronized. If you use only DTS to write data to the destination database, you can use Data Management (DMS) to perform online DDL operations on source tables during data synchronization. For more information, see Change schemas without locking tables. During data synchronization, we recommend that you use only DTS to write data to the destination database. This prevents data inconsistency between the source and destination databases. For example, if you use tools other than DTS to write data to the destination, data loss may occur in the destination when you use DMS to perform online DDL operations. By default, DTS disables FOREIGN KEY constraints for the destination database in a data synchronization task. Therefore, the cascade and delete operations of the source database are not synchronized to the destination database.

Billing rules

• The following billing rules are applicable to the physical migration method:

  You are not charged for data migration from the source ApsaraDB RDS for MySQL instance to the PolarDB for MySQL cluster. You are charged only for purchasing the PolarDB for MySQL cluster. For more information, see Billable items.PolarDB for MySQL

• The following billing rules are applicable to the logical migration method:

  You are charged for both purchasing PolarDB for MySQL clusters and creating data synchronization tasks on DTS. However, the upgrade feature is in the free-trial phase. No fees are charged for a synchronization task within 30 days after it is created. The following table describes the billing rules for the logical migration method.

  Migration object	Pricing
  Schema synchronization and full data synchronization	No fees are charged for a synchronization task within 30 days after it is created. After more than 30 days, the synchronization task will be canceled. Note You can go to the Data Synchronization page of the new DTS console to view the remaining time of the synchronization task.

The following sections describe the procedure to create a PolarDB for MySQL cluster by cloning an ApsaraDB RDS for MySQL instance.

Precheck whether the service-linked role for PolarDB is created (only for logical migration)

Before you use the logical migration (data synchronization over DTS) method to perform a one-click cloning, check whether the service-linked role for PolarDB has been created for the current Alibaba Cloud account. Perform the following steps to register the media assets:

1. Log on to the RAM console. In the left-side navigation pane, choose Identities > Roles.
2. Check whether a service-linked role named AliyunServiceRoleForPolarDB as shown in the following figure already exists in the list.
   
3. If yes, perform Step 1: Migrate data from the source ApsaraDB RDS for MySQL instance. If not, you must create the role.
4. In the upper-left corner, click Create Role.
5. In the Select Role Type step, select Alibaba Cloud Service and click Next.
   
6. In the Configure Role step, set Role Type to Service Linked Role and Select Service to ApsaraDB for PolarDB.
   
7. Click OK. In the Roles list, confirm that the role is created.

Step 1: Migrate data from the source ApsaraDB RDS for MySQL instance

In this step, a PolarDB for MySQL cluster is created. The cluster stores the same data as the source ApsaraDB RDS for MySQL instance.

1. Log on to the PolarDB console.
2. In the upper-left corner of the console, select the region in which the cluster that you want to manage is deployed.
3. Click Create Cluster.
4. Set Product Type to Subscription or Pay-As-You-Go.
   • Subscription: When you create a cluster, you must pay for the compute nodes. You are charged for the use of storage resources and the costs are deducted from your account balance on an hourly basis.
   • Pay-as-you-go: An upfront payment is not required. You are charged for the compute nodes and the amount of storage that is consumed by your data. These costs are deducted from your account balance on an hourly basis.

   Note For more information about the comparison between the subscription and pay-as-you-go billing methods, see Compute node billing methods and select a product type that is applicable to your business scenarios.
5. Specify the parameters described in the following table.
   Note For more information about the parameters that are not described in the following table, see Purchase a pay-as-you-go cluster or Purchase a subscription cluster.

   Parameter	Description
   Creation Method	Select Clone from RDS.
   Region	The region where the source ApsaraDB RDS for MySQL instance is deployed. Note The PolarDB for MySQL cluster to be created must also be deployed in this region.
   Source RDS Engine	The database engine of the source ApsaraDB RDS for MySQL instance. The default value of this parameter is MySQL and cannot be changed.
   Source RDS Version	The engine version of the source RDS instance. You can select 5.6, 5.7, or 8.0.
   Source RDS Instance	The source ApsaraDB RDS for MySQL instance. The available source ApsaraDB RDS for MySQL instances exclude read-only instances.
   Database Engine	The database engine version of the destination PolarDB for MySQL cluster. You can select the same version as the source ApsaraDB RDS for MySQL instance or a different version.
   Node Specification	The node specifications of the cluster. You can specify node specifications based on your business requirements. We recommend that you select specifications that are the same as or more advanced than the specifications of the source ApsaraDB RDS for MySQL instance. For more information about PolarDB for MySQL node specifications, see Specifications of compute nodes.

6. If you create a subscription cluster, configure Purchase Plan and Number and click Buy Now on the right side.
7. On the Confirm Order page, confirm your order information. Read and accept the terms of service, and then click Buy Now.
8. On the Purchase page, confirm the information of the unpaid order and the payment method, and then click Purchase.
9. Log on to the PolarDB console and check the status of the new PolarDB for MySQL cluster.
   Note If the logical migration method is used, click the cluster ID to go to the Overview page and view the migration status. If the Status field in the RDS Migration section is Precheck Failed, follow the instructions in the error message to troubleshoot the issue.

   For example, if a trigger is created in the source ApsaraDB RDS for MySQL instance, the precheck fails and the "The RDS instance has a trigger" error message is reported. If you confirm that the data remains consistent, you can click Continue to skip the verification when the "The RDS instance has a trigger" error message is reported during the precheck. If data inconsistency may occur, you can delete the trigger and then click Continue. Al ternatively, you can click Abandon and then manually create a data synchronization task in the DTS console. For more information, see Configure a data synchronization task for a source database that contains a trigger.

   You can also cancel the migration task. For more information, see FAQ.

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

If the logical migration method is used, click the cluster ID to go to the Overview page and view the migration status. If migration errors (such as a precheck failure) or other exceptions (such as very high replication latency) occur, you can go to the details page of the data synchronization task to view the details.

1. Log on to the PolarDB console.
2. Find the cluster and click the cluster ID.
3. In the RDS Migration section of the Overview page, click the name of DTS Data Synchronization Task to go to the data synchronization task list in the DTS console.
   
4. Find the data synchronization task. You can view precheck failure details, data synchronization task details, and data synchronization task logs.
   

FAQ

• What are the differences between creating a PolarDB for MySQL cluster by upgrading an ApsaraDB RDS for MySQL instance and creating a PolarDB for MySQL cluster by cloning an ApsaraDB RDS for MySQL instance?

  The following table describes the differences.

  Item	Create a PolarDB for MySQL cluster by upgrading an ApsaraDB RDS for MySQL instance	Create a PolarDB for MySQL cluster by cloning an ApsaraDB RDS for MySQL instance
  Whether incremental data migration or synchronization is supported	Yes.	No.
  Whether operations on the source ApsaraDB RDS for MySQL instance are affected	No	No
  Whether the source and destination can run different MySQL versions	Yes	Yes

• Is the source ApsaraDB RDS for MySQL instance affected when data is cloned from the ApsaraDB RDS for MySQL instance?

  No, the source ApsaraDB RDS for MySQL instance is not affected when data is migrated from the ApsaraDB RDS for MySQL instance.

• What happens if I cancel the migration?

  After the migration is canceled, you can modify the parameters of the source ApsaraDB RDS for MySQL instance. The read/write state of the PolarDB for MySQL cluster is changed to Read and Write, and the data in the cluster is not deleted. If you manually cancel the migration, you can specify whether to disable the binary logging feature for the PolarDB for MySQL cluster. Binary logging is not disabled if the migration is automatically canceled.

Related API operations