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

Benefits

• The endpoint of the source database are retained. You can switch to PolarDB without changing the connection settings of your applications.
• You can complete data migration in the PolarDB console without. No data migration tool such as data transmission service (DTS) is required.
• The data migration feature is free of charge.
• 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. A transient connection error occurs only once 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 source RDS instance uses ApsaraDB RDS for MySQL 5.6 or 5.7 High-availability Edition. The storage type is the local SSD.
• • For ApsaraDB RDS for MySQL 5.6, the minor version of the kernel for the RDS instance is 20190130 or later.
  • For ApsaraDB RDS for MySQL 5.7, the minor version of the kernel for the RDS instance is 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 RDS instance. For more information about how to upgrade the minor version of the kernel, see Update the minor engine version of an ApsaraDB RDS for MySQL instance.
• Transparent data encryption (TDE) and secure sockets layer (SSL) are disabled on the source RDS instance.
• The source RDS instance uses InnoDB as the table storage engine.
• If the RDS instance is running in the proxy mode (safe mode), a privileged account is created. Otherwise, the instance is switched to the high-performance mode. For more information, see Create a privileged account and [Important] RDS network link upgrade.

Switch 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 automatically 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. Other configurations are not interchanged, such as the configurations of the vSwitches and virtual IP addresses.
• 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.
• To switch to other endpoints, create these endpoints before the switchover. For more information about how to create endpoints for the PolarDB cluster, see View or apply for an endpoint. 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. Therefore, 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 about how to change the port number, 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. Select Subscription or Pay-as-you-go as Product Type.
   • Subscription: If you use the subscription billing method, you must pay for compute nodes when you create the cluster. You are charged for the consumed storage space by hour. The fees are deducted from your account balance on an hourly basis.
   • Pay-as-you-go: If you use the pay-as-you-go billing method, you are charged for the used resources. You are charged for compute nodes and the consumed storage by hour. The fees are deducted from your account balance on an hourly basis.
5. Specify the following parameters.

   Parameter	Description
   Region	The region where the source RDS instance is deployed. Note The PolarDB cluster to be created must also be deployed in this region.
   Create Type	Select Migration from RDS. Full 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 is in read-only mode and the binary logging feature is enabled for the PolarDB cluster before the switchover.
   RDS Engine Type	The engine type 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 available source RDS instances that exclude read-only instances. Select an RDS instance from the drop-down list.
   Primary Availability Zone	Each zone is an independent geographical location that is in a region. All the zones in a region provide the same services. You can deploy your PolarDB cluster and the Elastic Compute Service (ECS) instance in the same zone or in different zones. You need to select only the primary zone. The system automatically 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 is connected. 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. This compromises 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 Standard (2-16 nodes) (Recommended). You do not need to change this value.
   Node Specification	The node specification of the cluster. You can specify a node specification based on your business requirements. We recommend that you select a specification that is the same or higher than the specification of the source RDS instance. For more information, see For more information about PolarDB nodes, 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 automatically creates a read-only node that has the same specification as the primary node.
   Storage Cost	The storage cost. You do not need to specify this parameter. You are charged for the used storage on an hourly basis. For more information, see Specifications and pricing. Note You do not need to select a storage capacity when you create a cluster. The system automatically scales the storage capacity based on the amount of data to be stored.
   Time Zone	The time zone of the cluster. The default value is UTC+08:00.
   Table Name Case Sensitivity	Specifies whether table names are case-sensitive. The default value is Not Case-sensitive. If table names are case-sensitive in your on-premises database, we recommend that you select Case-sensitive. This ensures that you can migrate data in an easy way. 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 after the cluster is deleted or released. The default value is Retain Last Automatic Backup (Automatic Backup before Release). Retain Last Automatic Backup (Automatic Backup before Release): the last backup is retained after you delete the cluster. Retain All Backups: all backups are retained after you delete the cluster. Delete All Backups (Cannot be restored): no backup is retained after you delete the cluster. Note You may be charged for the backups that are retained after you delete or release a cluster. You can delete the backups to reduce costs. For more information, see Billable items.
   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 automatically 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 about how to create a resource group, see Create a resource group. Note A resource group is a container that contains a group of resources in an Alibaba Cloud account. You can perform centralized management on these resources. 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 the Purchase Plan and Number parameters, and then 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 the following link:
     • MySQL: Billing method 1: pay-as-you-go
     • PostgreSQL: Together with storage plans
     • Oracle: Together with storage plans
8. On the Purchase page, confirm the unpaid order and the payment method and click Purchase.
   Note After you complete the payment, it requires 10 to 15 minutes to create the cluster. Then, the newly created cluster is displayed on the Clusters page.
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 status of the source RDS instance and the destination PolarDB cluster are interchanged. The read/write status of the source RDS instance is changed to Read Only, and the read/write status 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 automatically 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 status 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 status is displayed 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 will be automatically restarted.
   • If the source RDS instance is no longer used, 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 status before the data migration. After the rollback, the read/write status of the source RDS instance is changed to Read and Write, and the read/write status 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 automatically 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 status of the source RDS instance is changed to Read and Write, and the read/write status 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 status of the source RDS instance is changed to Read and Write, and the read/write status 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 create a ApsaraDB PolarDB MySQL-compatible edition cluster fron an Apsara RDS for MySQL instance, Create a PolarDB for MySQL cluster by using the Clone from RDS method, and 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 fron an Apsara RDS for MySQL instance	Create a PolarDB for MySQL cluster by using the Clone from RDS method	Migrate data from an ApsaraDB RDS for MySQL instance to a PolarDB for MySQL cluster
  Requires DTS	×	×	√
  Supports incremental data migration or synchronization	√	×	√
  Affects operations on the source RDS instance	×	×	×
  Uses different MySQL versions for the source and destination databases	×	×	√

  Note √ in the table indicates supported or required, and × indicates not supported or not required.
• Do the node specifications of ApsaraDB PolarDB MySQL-compatible edition need to be the same as that 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 the specifications that are not lower 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 with 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 causes read operations, which consume 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 no data loss during the migration. The service downtime is less than 10 minutes. During the service downtime, the service is suspended and does not generate incremental data. However, 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 status 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 automatically 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. To switch to other endpoints, create these endpoints before the switchover. For more information about how to create endpoints for the PolarDB cluster, see View or apply for an 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, why do I fail to connect to PolarDB databases or fail to write data to the databases?

  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 PolarDB for MySQL cluster by using the Clone from RDS method 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 not appear in the PolarDB console after I switch over services?

  If you complete the Complete Migration step, this button disappears. This avoids repeat 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 a migration from a source RDS instance that has TDE or SSL enabled to the PolarDB cluster?

  RDS instances with 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, will the task be 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 migration is completed, if you switch your services to the new PolarDB cluster and the source RDS instance is no longer used, the data source of DTS will not be automatically changed to the new PolarDB cluster. In this case, you must create a new DTS synchronization task and change the data source to the PolarDB cluster.

Related operations