Create a PolarDB for MySQL cluster from an ApsaraDB RDS for MySQL instance

Features

• Data migration is free of charge.
• No data loss during data migration.
• Supports incremental data migration. This allows you to migrate data with a service downtime of less than 10 minutes.
• Supports migration rollback. If a migration fails, it can be rolled back within 10 minutes.
• Supports switchover with endpoint interchange. You do not need to change the configurations of your applications to reconnect to Apsara PolarDB.

Procedure

1. Create an Apsara PolarDB cluster to store the same data as the source RDS instance. Incremental data is then dynamically synchronized from the source RDS instance to the Apsara PolarDB cluster. For more information, see Migrate data from the source RDS instance.
   Note You must change the database endpoint in your applications to the endpoint of the Apsara PolarDB cluster, verify that your workloads are running properly, and click Complete Migration within seven days. After you click Complete Migration, the system stops synchronizing data between the source RDS instance and the Apsara PolarDB cluster.
2. Click Switch. The operation reverses the migration to synchronize incremental data from the Apsara PolarDB cluster to the RDS instance. After the synchronization is complete, the source RDS instance is switched to the read-only mode and the Apsara PolarDB cluster is switched to the read/write mode. Modify the database endpoint in your applications at the earliest opportunity. For more information, see Perform a reverse migration.
   Note After the reverse migration is complete, you can also roll back the migration.
3. Complete the migration.

Limits

• The source RDS instance and the Apsara PolarDB cluster must be deployed in the same region.
• The parameters of the source RDS instance cannot be modified during migration.

Migrate data from the source RDS instance.

1. Log on to the Apsara PolarDB console.
2. Click Create Cluster.
3. Select Subscription or Pay-as-you-go.
4. Configure the following parameters.

   Parameter	Description
   Region	Select the region where the ApsaraDB RDS for MySQL instance is deployed. Note The new Apsara PolarDB cluster is also deployed in this region.
   Create Type	Select Migration from RDS. Apsara PolarDB uses this method to clone a cluster from the source RDS instance. It keeps data synchronized between the RDS instance and the Apsara PolarDB cluster. By default, the binary log of the new cluster is enabled.
   RDS Engine Type	The engine type of the source RDS instance, which cannot be modified.
   RDS Engine Version	The engine version of the source RDS instance, which cannot be modified.
   Source RDS instance	Select an available RDS instance from the drop-down list. Read-only RDS instances are not listed.
   Primary Availability Zone	The zone of the cluster. Each zone is an independent geographical location within a region. The zones that are deployed in the same region are similar. You can deploy your Apsara PolarDB cluster and the ECS instance in the same zone or in different zones.
   Network Type	The network type of the Apsara PolarDB cluster that cannot be modified.
   VPC VSwitch	The VPC network and VSwitch to which the Apsara PolarDB cluster is connected. Make sure that the Apsara PolarDB cluster and ECS instance are deployed in the same VPC network. Otherwise, the cluster and the ECS instance cannot communicate with each other over the internal network and achieve optimal performance.
   Compatibility	The database engine of the Apsara PolarDB cluster that which cannot be modified.
   Node Specification	Select a node specification for the Apsara PolarDB cluster based on your workload requirements. We recommend that you select a specification that is the same or higher than that of the source RDS instance. All nodes in the Apsara PolarDB cluster are dedicated nodes with stable performance. For more information, see Specifications and pricing.
   Nodes	The number of nodes in the new cluster. Keep the default setting. The system automatically creates a read-only node with the same specification as that of the primary node.
   Storage Cost	You do not need to specify this parameter. Storage fees are charged based on the usage on an hourly basis. For more information, see Specifications and pricing.

5. Specify the Purchase Plan parameter if you are creating a subscription cluster, and then click Buy Now on the right side of the page.
6. Confirm the order information, read the Agreement of Service, select the check box, and then click Pay.
7. Log on to the Apsara PolarDB console and check the status of the new Apsara PolarDB cluster.
   Note

   • After the cluster is created, it synchronizes data from the source RDS instance. You must modify the database endpoint in your applications and click Complete Migration within seven days. The data migration task is automatically terminated after seven days.
   • You can also cancel the migration. For more information about the impacts of cancelling a migration task, see FAQ.

Perform a reverse migration

You can perform a reverse migration to synchronize data from the Apsara PolarDB cluster to the RDS instance if the following conditions are met, and then change the database endpoint in your applications.

• You have completed tasks described in Migrate data from the source RDS instance..
• The value of Replication Latency must be less than 60 seconds.

1. Log on to the Apsara PolarDB console.
2. Find the target cluster and click the cluster ID.
3. On the Overview page, click Switch. In the dialog box that appears, click OK. The operation reverses the migration to synchronize incremental data from the Apsara PolarDB cluster to the RDS instance. After the synchronization is completed, the source RDS instance is switched to the read-only mode and the Apsara PolarDB cluster is switched to the read/write mode.
   Note

   • You cannot perform a reverse migration if the replication latency is higher than 60 seconds.
   • In most cases, the reverse migration process lasts less than 5 minutes.
4. In the Start Switching dialog box, select Switch with Endpoints Interchange (Connection Changes Not Required) or Switch with Endpoints Interchange (Connection Changes Required).
   

   If you do not want to change the connection configurations of your applications, select Switch with Endpoints Interchange (Connection Changes Not Required). After you select Switch with Endpoints Interchange, refer to the correspondence between the endpoint of the RDS instance and the endpoint of Apsara PolarDB cluster, as shown in the following figure.

   

   Notice

   • If you select Switch with Endpoints Interchange, only the domain names of ApsaraDB for RDS and Apsara PolarDB are interchanged. Other configurations such as the VSwitches and VIPs are not interchanged.
   • If you select Switch with Endpoints Interchange, the port numbers are not interchanged. Make sure that the port number of the ApsaraDB for RDS instance is the same as that of the Apsara PolarDB cluster. For more information, see View the internal and public endpoints and ports of an RDS MySQL instance.
   • After domain names are interchanged, a DNS cache issue may occur. You may fail to connect to the database before the DNS cache expires. To resolve this issue, we recommend that you refresh the DNS cache.
   • If you want to use Data Management Service (DMS) to log on to the Apsara PolarDB database, you must use the latest version of DMS and log on to the database with the cluster ID.
5. Click OK.
6. Refresh the page. After PolarDB Read/Write Status changes to Read and Write, change the database endpoint in your applications at the earliest opportunity.
   Note During the reverse migration, you can also roll back the migration.

Complete migration

1. Log on to the Apsara PolarDB console.
2. Find the target cluster and click the cluster ID.
3. On the Overview page, click Complete Migration. In the dialog box that appears, click OK.
   Note

   • After you click OK, the system stops data synchronization within two minutes. During this process, the Complete Migration button is still available. Do not click it again.
   • You can choose whether to disable the binary log feature for the Apsara PolarDB cluster. If this feature is disabled, the write performance can be slightly improved. However, you must restart the Apsara PolarDB cluster.
4. Release the source RDS instance if it is no longer needed.

Roll back the migration

Before a migration is complete, you can also roll back the migration. After the rollback operation is complete, the source RDS instance is switched to the read/write mode, and the Apsara PolarDB cluster is switched to the read-only mode. The system synchronizes data from the source RDS instance to the Apsara PolarDB cluster.

1. Log on to the Apsara PolarDB console.
2. Find the target cluster and click the cluster ID.
3. On the Overview page, click Rollback. In the dialog box that appears, click OK.
   Note After you click OK, the system synchronizes data from the source RDS instance to the Apsara PolarDB cluster. After the rollback operation is complete, the source RDS instance is switched to the read/write mode and the Apsara PolarDB cluster is switched to the read-only mode. After Source RDS Read/Write Status is displayed as Read and Write, change the database endpoint in your applications to the endpoint of the RDS instance at the earliest opportunity.

FAQ

• Is the source RDS instance affected when data is migrated from the RDS instance?

  No, the source RDS instance can run properly.

• Does smooth migration affect my workloads running on the connected databases?

  Smooth migration ensures zero data loss during migration. The service downtime is less than 10 minutes. You can roll back the migration if necessary.

• What happens if I cancel the migration?

  After the migration is canceled, you can modify the parameters of the source RDS instance. The Apsara PolarDB cluster is switched to the read/write mode, and the data is not released. If you manually cancel the migration, you can choose whether to disable the binary log feature for the Apsara PolarDB cluster. The binary log feature is not disabled if the migration is automatically canceled.

Related API operations