Create a ApsaraDB PolarDB MySQL-compatible edition cluster by migrating an ApsaraDB RDS for MySQL instance

Benefits

• The endpoint of the source database is retained. You can switch to PolarDB without changing the connection settings of your applications.
• You can complete data migration in the PolarDB console. No data migration tools such as Data Transmission Service (DTS) are required.
• The data migration feature is free of charge to use.
• No data loss occurs during the migration.
• Incremental data migration is supported. This allows you to migrate data with a service downtime of less than 10 minutes.
• Hot migration is supported. Only a single transient disconnection occurs during the data migration from ApsaraDB RDS for MySQL to PolarDB.
• Migration rollbacks are supported. If a migration fails, the migration can be rolled back within 10 minutes.

Prerequisites

• The edition of the source RDS instance is ApsaraDB RDS for MySQL 5.6 or 5.7 High-availability Edition, and the storage type is local SSD.
• • For ApsaraDB RDS for MySQL 5.6, the minor version of the kernel must be 20190815 or later.
  • For ApsaraDB RDS for MySQL 5.7, the minor version of the kernel must be 20200331 or later.
  Note You can run the show variables like '%rds_release_date%'; command to view the minor version of the kernel for the source RDS instance. If the minor version of the kernel for the source RDS instance is earlier than the preceding version, you can upgrade the minor version of the kernel 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 RDS instance. For more information, see TDE and SSL.
• The table storage engine for the source RDS 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 high-performance mode. For more information, see Create a privileged account and [Important] RDS network link upgrade.

Switching with endpoints

When you perform data migration from ApsaraDB RDS for MySQL to PolarDB, you can select Switch with Endpoints (Connection Changes Not Required). Then, the system interchanges the endpoints between the RDS instance and the PolarDB cluster. In this case, you do not need to modify the configurations of your applications to connect to the PolarDB cluster. The following figure shows the rules for endpoint interchanges between the RDS instance and the PolarDB cluster.

To switch with endpoints, take note of the following limits:

• Only the endpoints of the RDS instance and the PolarDB cluster are interchanged. The other configurations such as the vSwitches and virtual IP addresses remain the same as before.
• Endpoints can be interchanged only if both the source RDS instance and the destination PolarDB cluster have endpoints. By default, only the primary endpoints in the internal network can be interchanged.
• If you want to switch to a different endpoint, you must create these endpoints before the switchover. For more information about how to create endpoints for the PolarDB cluster, see Configure the PolarDB proxy. For more information about how to create endpoints for the RDS instance, see Configure endpoints for an RDS instance.
• The port numbers are not interchanged between the RDS instance and the PolarDB cluster. You must make sure that the port number of the RDS instance is the same as that of the PolarDB cluster. The default port number used by RDS and PolarDB is 3306. If the port numbers are different, change one of the port numbers. For more information, see View and change the internal and public endpoints and port numbers of an ApsaraDB RDS for MySQL instance and Modify or delete an endpoint.
• After the endpoints are interchanged, issues may occur due to the expiration of the Domain Name System (DNS) cache data. The databases in the PolarDB cluster may fail to be connected or support only read operations. We recommend that you refresh the DNS cache data of your server to fix this issue.
• If you want to use Data Management (DMS) to log on to the PolarDB database after the endpoints are interchanged, you must use the latest version of DMS and the cluster ID to log on to the database. You cannot log on to the database by using the endpoint.

Limits

• Cross-region data migration is not supported.
• You cannot set the parameters of the source RDS instance during data migration.

Pricing

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

Procedure

Step 1: Migrate data from the source RDS instance

In this step, a PolarDB cluster is created. The cluster stores the same data as the source RDS instance. Then, incremental data is synchronized from the source RDS instance to the PolarDB cluster in real time.

1. Log on to the PolarDB console.
2. In the upper-left corner of the console, select the region where the cluster is deployed.
3. Click Create Cluster.
4. Set Product Type to Subscription or Pay-As-You-Go.
   • Subscription: If you select this billing method, you must pay for compute nodes when you create the cluster. You are charged by hour for the amount of storage space consumed by your data. The fees are deducted from your account on an hourly basis.
   • Pay-As-You-Go: If you use this billing method, you are charged for the used resources. An upfront payment is not required. You are charged by hour for the compute nodes and the amount of storage space consumed by your data. These fees are deducted from your account on an hourly basis.
5. Set the following parameters.

   Parameter	Description
   Region	The region where the source ApsaraDB RDS for MySQL instance resides. Note The PolarDB cluster to be created must also be deployed in this region.
   Create Type	Select Migration from RDS. All of the data is cloned from the source RDS instance. Then, incremental data is synchronized from the source RDS instance to the PolarDB cluster in real time. By default, the PolarDB cluster enters read-only mode and the binary logging feature is enabled for the PolarDB cluster before the switchover.
   RDS Engine Type	The database engine of the source RDS instance. The default value of this parameter is MySQL and cannot be changed.
   RDS Engine Version	The engine version of the source RDS instance. You can select 5.6 or 5.7.
   Source RDS Instance	The source RDS instance. The available source RDS instances exclude read-only instances.
   Primary Availability Zone	Each zone is an independent geographical location in a region. All zones in a region provide the same services. You can choose to create your PolarDB cluster in the same zone as the Elastic Compute Service (ECS) instance or in the zone that is different from the zone of this instance. You need to specify only the primary zone. The system selects a secondary zone.
   Network Type	The network type of the PolarDB cluster. The value of this parameter cannot be changed.
   VPC VSwitch	The VPC and the vSwitch to which the PolarDB cluster belongs. Make sure that the PolarDB cluster and the ECS instance to be connected are deployed in the same VPC. Otherwise, the cluster and the ECS instance cannot communicate over the internal network to achieve the optimal performance.
   Compatibility	The database engine version of the PolarDB cluster. The default version is the same as the engine version of the source RDS instance and cannot be changed.
   Edition	The edition of the cluster. This parameter is automatically set to Cluster (2-16 Nodes) (Recommended). You do not need to specify this parameter.
   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 RDS instance. For more information about PolarDB node specifications, see Specifications of compute nodes.
   Nodes	The number of nodes to be created in the cluster. You do not need to specify this parameter. The system creates a read-only node of the same specifications as the primary node.
   Storage Cost	The storage cost. You do not need to specify this parameter. You are charged by hour for the storage space that is consumed by the actual amount of data. For more information, see Specifications and pricing. Note You do not need to specify the storage capacity when you create a cluster. The system scales the storage capacity when the amount of data is increased or decreased.
   Time Zone	The time zone of the cluster. The default value is UTC+08:00.
   Table Name Case Sensitivity	Specifies whether the table names of the cluster are case-sensitive. The default value is Not Case-sensitive (Default). If your on-premises database has case-sensitive table names, select Case-sensitive to facilitate data migration. Note The value of this parameter cannot be changed after the cluster is created. Proceed with caution.
   Release Cluster	The backup retention policy that is used when you delete or release the cluster. Default value: Retain Last Automatic Backup (Automatic Backup before Release) (Default). Valid values: Retain Last Automatic Backup (Automatic Backup before Release) (Default): retains the last backup when you delete the cluster. Retain All Backups: retains all backups when you delete the cluster. Delete All Backups (Cannot be restored): deletes all backups when you delete the cluster. Note If you choose to retain backups when you delete the cluster, you may be charged for the backups. You can delete the backups to reduce costs. For more information, see Billing rules of backup storage that exceeds the free quota.
   Cluster Name	The name of the new cluster. It must be 2 to 128 characters in length and can contain letters, digits, periods (.), underscores (_), and hyphens (-). It must start with a letter. If you leave this parameter empty, the system generates a cluster name. You can change the cluster name after the cluster is created.
   Resource Group	The resource group of the cluster. Select a resource group from available resource groups. For more information, see Create a resource group. Note A resource group contains a group of resources that belong to an Alibaba Cloud account. Resource groups allow you to manage these resources in a centralized manner. A resource belongs to only one resource group. For more information, see Use RAM to create and authorize resource groups.

6. If you create a subscription cluster, set Purchase Plan and Number and click Buy Now in the right corner.
7. On the Confirm Order page, confirm your order information. Read and accept the terms of service, and then click Activate Now.

   After you complete the activation, it takes 10 to 15 minutes to create the cluster. Then, the newly created cluster is displayed on the Clusters page.

   Note

   • If nodes in the cluster are in the Creating state, the cluster is being created and unavailable. The cluster is available only if it is in the Running state.
   • Make sure that you have selected the region where the cluster is deployed. Otherwise, you cannot view the cluster.
   • We recommend that you purchase subscription PolarDB storage plans to store a large amount of data. Storage plans are more cost-effective than pay-as-you-go storage. You are offered larger discounts if you purchase storage plans that provide larger storage capacities. For more information, see Together with storage plans.
8. On the Purchase page, confirm the unpaid order and the payment method and click Purchase.
9. After the cluster is created, log on to the PolarDB console and check that the Replication Delay of the PolarDB cluster is less than 60 seconds. Then, you can go to Step 2: Switch over services.
   

   Note

   • After the cluster is created, the system starts to migrate data from the RDS instance to the cluster. You must click Complete Migration in the PolarDB console within seven days after the cluster is created. Otherwise, the migration task is automatically terminated after seven days.
   • You can also cancel the migration task. For more information about the impacts of canceling a migration task, see FAQ.

Step 2: Switch over services

1. Log on to the PolarDB console.
2. Find the cluster and click the cluster ID.
3. On the Overview page, click Switch.
   

   Note

   • In most cases, it requires less than 5 minutes for the system to compete the switchover.
   • After the switchover, the read/write states of the source RDS instance and the destination PolarDB cluster are interchanged. The read/write state of the source RDS instance is changed to Read Only, and the read/write state of the PolarDB cluster is changed to Read and Write. The replication direction is also changed. This way, the incremental data on the PolarDB cluster is synchronized to the RDS instance.
4. In the Start Switching dialog box, select Switch with Endpoints (Connection Changes Not Required) or Switch without Endpoints (Connection Changes Required).
   • If you select Switch with Endpoints (Connection Changes Not Required), perform the following steps:
     1. After you select Switch with Endpoints (Connection Changes Not Required), the system interchanges the endpoints between the RDS instance and the PolarDB cluster. You do not need to modify the configurations of your applications to connect to the PolarDB cluster.
        Notice Before you select Switch with Endpoints (Connection Changes Not Required), make sure that you have read the related notes.
     2. Click OK.
   • If you select Switch without Endpoints (Connection Changes Required), perform the following steps:
     1. Select Switch without Endpoints (Connection Changes Required). After the switchover, you must change the database endpoint in your application at the earliest opportunity.
     2. Click OK.
     3. Refresh the page. After PolarDB Read/Write Status becomes Read and Write, change the database endpoint in your application at the earliest opportunity.

   Note If data errors are found after the switchover, you can roll back the database to the state before the data migration. For more information, see Roll back the migration.

Step 3: Complete the migration

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

   • After you click OK, the system stops data synchronization within about 2 minutes. During this process, the state displayed is Disabling Synchronization. Wait until the migration is complete.
   • In the Complete Migration dialog box, you can specify whether to disable the binary logging feature for the PolarDB cluster. If this feature is disabled, the write performance can be slightly improved. However, the PolarDB cluster is automatically restarted.
   • If you no longer need to use the source RDS instance, you can release the instance.For more information, see Release or unsubscribe from an ApsaraDB RDS for MySQL instance.

Roll back the migration (optional)

If data errors occur before the migration is complete, you can roll back the migration. This allows you to restore the database and data to the state before the data migration. After the rollback, the read/write state of the source RDS instance is changed to Read and Write, and the read/write state of the PolarDB cluster is changed to Read Only. The system synchronizes data from the RDS instance to the PolarDB cluster.

1. Log on to the PolarDB console.
2. Find the cluster and click the cluster ID.
3. On the Overview page, click Rollback.
4. In the Switch Back dialog box, select Switch Back with Endpoints (Connection Changes Not Required) or Switch Back without Endpoints (Connection Changes Required).
   • If you select Switch Back with Endpoints (Connection Changes Not Required), perform the following steps:
     1. After you select Switch Back with Endpoints (Connection Changes Not Required), the system interchanges the endpoints between the RDS instance and the PolarDB cluster. You do not need to modify the configurations of your applications to connect to the RDS instance.
     2. Click OK. This way, the read/write state of the source RDS instance is changed to Read and Write, and the read/write state of the PolarDB cluster is changed to Read Only. The system synchronizes data from the RDS instance to the PolarDB cluster.
   • If you select Switch Back without Endpoints (Connection Changes Required), perform the following steps:
     1. Select Switch Back without Endpoints (Connection Changes Required). After the switchover, you must change the database endpoint in your application at the earliest opportunity.
     2. Click OK. This way, the read/write state of the source RDS instance is changed to Read and Write, and the read/write state of the PolarDB cluster is changed to Read Only. The system synchronizes data from the RDS instance to the PolarDB cluster.
     3. Refresh the page. After Source RDS Read/Write Status becomes Read and Write, change the database endpoint in your application to the endpoint of the RDS instance at the earliest opportunity.

FAQ

• What are the differences among creating a PolarDB for MySQL cluster by migrating an ApsaraDB RDS for MySQL instance (ApsaraDB PolarDB MySQL-compatible edition), creating an ApsaraDB PolarDB MySQL-compatible edition cluster by using the Clone from RDS method (Create a ApsaraDB PolarDB MySQL-compatible edition cluster by cloning an ApsaraDB RDS for MySQL instance), and migrating data from an ApsaraDB RDS for MySQL instance to a PolarDB for MySQL cluster (Migrate data from an ApsaraDB RDS for MySQL instance to a PolarDB for MySQL cluster)?

  The following table describes the differences.

  Item	Create a ApsaraDB PolarDB MySQL-compatible edition cluster by migrating an ApsaraDB RDS for MySQL instance	Create a ApsaraDB PolarDB MySQL-compatible edition cluster by cloning an ApsaraDB RDS for MySQL instance	Migrate data from an ApsaraDB RDS for MySQL instance to a PolarDB for MySQL cluster
  Whether DTS is required	No	No	Yes
  Whether incremental data migration or synchronization is supported	Yes	No	Yes
  Whether operations on the source RDS instance are affected	No	No	No
  Whether the source and destination databases can use different MySQL versions	No	No	Yes

  Note
• Do the node specifications of ApsaraDB PolarDB MySQL-compatible edition need to be the same as those of the source ApsaraDB RDS for MySQL instance?

  You can select the specifications of ApsaraDB PolarDB MySQL-compatible edition based on your business requirements. We recommend that you select specifications that are the same as or more advanced than those of the source RDS instance. All nodes in the PolarDB Cluster Edition cluster are dedicated nodes. The dedicated nodes provide stable and reliable performance. For more information, see Billable items.

• Do I need to purchase a ApsaraDB PolarDB MySQL-compatible edition cluster before the upgrade from RDS to PolarDB?

  You do not need to purchase a ApsaraDB PolarDB MySQL-compatible edition cluster in advance. You can perform the operations that are described in Step 1: Migrate data from the source RDS instance to purchase and create a PolarDB cluster that has the same data as the source RDS instance.

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

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

• What are the impacts of smooth migration on the RDS instance?

  The migration does not affect the operations on the source RDS instance. However, data migration involves read operations, and read operations affect query performance on the source RDS instance.

• What are the impacts of smooth migration on my workloads that run on the databases?

  A smooth migration ensures that no data is lost during the migration. The service downtime is less than 10 minutes. During service downtime, the service is suspended and does not generate incremental data but the database is not stopped. You can roll back the migration based on your business requirements.

• What happens if I cancel the migration?

  After the migration is canceled, you can modify the parameters of the source RDS instance. The read/write state of the PolarDB 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 cluster. Binary logging is not disabled if the migration is automatically canceled.

• Do I need to change the endpoint in my applications after the service is switched over to PolarDB?

  When you switch over services, you can select Switch with Endpoints (Connection Changes Not Required). Then, the system interchanges the endpoints between the RDS instance and the PolarDB cluster. In this case, you do not need to modify the configurations of your applications to connect to the PolarDB cluster.

• I select Switch with Endpoints (Connection Changes Not Required) when I switch over services. Why do I need to use the new endpoint to connect to the PolarDB cluster?

  Endpoints can be interchanged only if both the source RDS instance and the destination PolarDB cluster have endpoints. By default, only the primary endpoint in the internal network is interchanged. If you want to switch to a different endpoint, you must create these endpoints before the switchover. For more information about how to create endpoints for the PolarDB cluster, see Apply for a cluster endpoint or a primary endpoint. For more information about how to create endpoints for the RDS instance, see Configure endpoints for an RDS instance.

• If the source RDS instance contains read-only instances, can the endpoints of read-only instances be switched when Switch with Endpoints (Connection Changes Not Required) is selected?

  No, the endpoints of read-only instances cannot be switched. The endpoints of the source RDS read-only instances are not migrated when you upgrade from RDS to PolarDB. Only the endpoints and read/write splitting endpoints of the source RDS primary instance are migrated. You must manually modify the endpoints of the source RDS read-only instances in your applications to the endpoints of the PolarDB cluster.

• After the switchover, connections to the PolarDB databases cannot be made or data cannot be written to the databases. Why?

  After the endpoints are interchanged, issues may occur due to the expiration of the DNS cache data. The databases in the PolarDB cluster may fail to be connected or support only read operations. We recommend that you refresh the DNS cache to fix this issue.

• Can I perform a compatibility test and evaluate the workloads before the migration to the PolarDB cluster?

  You can first perform the operations described in Create a ApsaraDB PolarDB MySQL-compatible edition cluster by cloning an ApsaraDB RDS for MySQL instance to clone data to the PolarDB cluster for compatibility tests and workload evaluation. Then perform the operations in this topic to upgrade to PolarDB.

• Why does the Complete Migration button not appear in the PolarDB console after I switch over services?

  If you complete the Complete Migration step, this button disappears. This avoids repeated operations.

• After the upgrade to PolarDB, do I need to create the same username and password in the PolarDB cluster as those in the source RDS instance?

  No, you do not need to create the same username and password in the PolarDB cluster. The created PolarDB cluster retains the accounts, databases, IP address whitelist, and required parameters of the source ApsaraDB RDS for MySQL instance.

• How do I perform migration from a source RDS instance that has TDE or SSL enabled to the PolarDB cluster?

  RDS instances that have TDE or SSL enabled cannot be upgraded to PolarDB clusters. You can use DTS to migrate data from the source RDS instance to the PolarDB cluster. For more information, see Migrate data from an ApsaraDB RDS for MySQL instance to a PolarDB for MySQL cluster.

• Can I perform a cross-version upgrade when I create a PolarDB cluster by migrating an ApsaraDB RDS for MySQL instance? For example, can I upgrade from ApsaraDB RDS for MySQL 5.6 to ApsaraDB PolarDB MySQL-compatible edition 8.0?

  No, you cannot perform a cross-version upgrade. To upgrade ApsaraDB RDS for MySQL 5.6 to ApsaraDB PolarDB MySQL-compatible edition8.0, you must use DTS to migrate data. For more information, see Migrate data from an ApsaraDB RDS for MySQL instance to a PolarDB for MySQL cluster.

• If a DTS data synchronization task is started for the source RDS instance before the upgrade to ApsaraDB PolarDB MySQL-compatible edition, is the task affected during the upgrade?

  No, when you perform operations described in this topic, full data is first cloned from the source RDS instance to the new PolarDB cluster. Then, incremental data is synchronized from the source RDS instance to the PolarDB cluster in real time. The data source of the DTS task is still the source RDS instance. The data migration to the PolarDB cluster does not affect the operations on the source RDS instance.

  However, after the data is migrated, if you switch your services to the new PolarDB cluster and the source RDS instance is no longer used, the data source of DTS is not automatically changed to the new PolarDB cluster. In this case, you must create a DTS synchronization task and change the data source to the PolarDB cluster.

References