PolarDB:Procedure

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 an upgrade, check whether the service-linked role for PolarDB has been created and whether Data Transmission Service (DTS) has been authorized to access Alibaba Cloud resources. For more information, see Authorize DTS to access Alibaba Cloud resources. To check whether the service-linked role for PolarDB has been created, perform the following steps:

1. Log on to the Resource Access Management (RAM) console. In the left-side navigation pane, choose Identities > Roles.

2. Check whether a service-linked role named AliyunServiceRoleForPolarDB already exists in the list, as shown in the following figure.

   

3. If the service-linked role exists in the list, perform the operations in Step 1: Migrate data from the source ApsaraDB RDS for MySQL instance. If the service-linked role does not exist in the list, you must create the role.

4. In the upper-left corner, click Create Role.

5. In the Select Role Type step of the Create Role panel, select Alibaba Cloud Service and click Next.

   

6. In the Configure Role step, set Role Type to Service Linked Role and select ApsaraDB for POLARDB from the Select Service drop-down list.

   

7. Click OK. In the role list and then confirm that the role is created.

Remove redundant system accounts from the source ApsaraDB RDS instance (only for logical migration)

To ensure compatibility between ApsaraDB RDS for MySQL and PolarDB in terms of the system account structure and to prevent the system accounts of the destination PolarDB cluster from being overwritten during migration, make sure that the root and aliyun_root accounts do not exist in the source ApsaraDB for RDS instance at the same time. Before you initiate the migration process, we recommend that you remove redundant system accounts from the source ApsaraDB for RDS instance.

The following table lists the correct system account name for each version of ApsaraDB RDS for MySQL.

Apart from the corresponding system account for each version mentioned in the preceding table, all other system accounts must be removed.

The following example shows how to remove redundant system accounts from an ApsaraDB RDS for MySQL 5.6 instance:

1. Use a privileged account to connect to the instance.

2. Find all root and aliyun_root system accounts.

   select * from mysql.user where user in ('root', 'aliyun_root');

3. Remove redundant system accounts. The correct system account name of ApsaraDB RDS for MySQL 5.6 is root. Therefore, you must remove the aliyun_root account.

   delete from mysql.user where user = 'aliyun_root' limit n; 

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

In this step, create a PolarDB cluster that contains the same data as the source ApsaraDB RDS for MySQL instance. Then, incremental data is synchronized from the source ApsaraDB RDS for MySQL instance to the PolarDB cluster in real time.

1. Log on to the PolarDB console and click Create Cluster to go to the PolarDB buy page.

2. Set Billing Method 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 the "Comparison" section of the Overview topic.

3. Configure 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 Migration from RDS. Note By default, the PolarDB cluster is in the read-only mode and the binary logging feature is enabled for the PolarDB cluster before the switchover.
   Region	The region where the source ApsaraDB RDS for MySQL instance is deployed. Note The destination PolarDB cluster must also be deployed in this region.
   RDS Engine Type	The database engine of the source ApsaraDB RDS instance. The default value of this parameter is MySQL and cannot be changed.
   RDS Engine Version	The database engine version of the source ApsaraDB RDS for MySQL instance. Valid values: 5.6, 5.7, and 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 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 higher than the specifications of the source ApsaraDB RDS for MySQL instance. For more information about PolarDB node specifications, see Compute node specifications of PolarDB for MySQL Enterprise Edition.
   Storage Engine	PolarDB supports the following engine types: InnoDB and InnoDB & X-Engine. InnoDB: deploys only the InnoDB storage engine. InnoDB & X-Engine:: deploys InnoDB and X-Engine. If you select this option, specify the X-Engine memory usage ratio. For more information, see X-Engine Edition.

4. If you want to create a subscription cluster, configure Purchase Plan and Number and click Buy Now in the lower-right corner.

5. On the Confirm Order page, confirm your order information. Read and accept the terms of service, and then click Activate Now.

   After you activate the service, it requires 10 to 15 minutes to create the cluster. Then, the created cluster is displayed on the Clusters page.

   Note

   • If specific nodes in the cluster are in the Creating state, the cluster is still being created and is unavailable. The cluster is only available when the cluster is in the Running state.

   • Make sure that you select the region where the cluster is deployed. Otherwise, you cannot view the cluster.

   • If you want to store a large amount of data, we recommend that you purchase PolarDB storage plans. Storage plans are more cost-effective than pay-as-you-go storage. Larger storage plans provide more storage at lower costs. For more information, see Combination with storage plans.

6. If the billing method of the cluster is subscription, the Purchase page appears. Confirm the order and the payment method, and click Subscribe.

7. After the cluster is created, log on to the PolarDB console and click the cluster ID to go to the Basic Information page of the cluster.

8. In the RDS Migration section of the Basic Information page, check the Replication Latency value of the destination PolarDB cluster. If the value is smaller than 60 seconds, perform the operations in Step 2: Switch over services.

   

   Note

   • After the cluster is created, the system starts to migrate data from the ApsaraDB RDS for MySQL instance to the cluster. You must perform the operations in Step 3: Complete the migration within 30 days after the cluster is created. Otherwise, the migration task is automatically terminated after 30 days.

   • If the logical migration method is used and the Status value displayed in the RDS Migration section is Precheck Failed after the PolarDB cluster is created, 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. You can delete the trigger and then click Continue. Alternatively, you can click Cancel 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 click Cancel in this step. For more information, see FAQ.

Step 2: Switch over services

If the Replication Latency value of the destination PolarDB cluster is smaller than 60 seconds, you can perform the switchover operation.

1. Log on to the PolarDB console.

2. Find the cluster and click the cluster ID.

3. In the RDS Migration section of the Basic Information page, click Switch Over Business.

   

   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 ApsaraDB RDS for MySQL instance and the destination PolarDB cluster are interchanged. The read/write state of the source ApsaraDB RDS for MySQL 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. In this case, incremental data is synchronized from the PolarDB cluster to the ApsaraDB RDS for MySQL instance.

4. In the Start Switchover dialog box, select Switch with Endpoints (Connection Changes Not Required) or Switch without Endpoints (Connection Changes Required).

   • Switch with Endpoints (Connection Changes Not Required):

     1. If you select Switch with Endpoints (Connection Changes Not Required), the system interchanges the endpoints between the ApsaraDB RDS for MySQL instance and the PolarDB cluster. You do not need to modify the configurations of your application to connect to the PolarDB cluster.

        Important

        Before you select Switch with Endpoints (Connection Changes Not Required), make sure that you read the notes for switchover with endpoints.

     2. Click OK.

   • Switch without Endpoints (Connection Changes Required):

     1. Select Switch without Endpoints (Connection Changes Required).

        Important

        After the switchover is complete, you must modify the database endpoint in the application at the earliest opportunity to prevent prolonged connection interruptions.

     2. Click OK.

     3. Refresh the page. If the value of PolarDB Read/Write Status becomes Read/Write, change the database endpoint in your application at the earliest opportunity.

   Note

   • If data errors occur after the migration is complete, you can roll back the migration. This allows you to restore the database and data to the original state before the migration is performed. For more information, see (Optional) Roll back the migration.

   • If you select Switch with Endpoints, after the switchover, all nodes of the ApsaraDB RDS for MySQL instance become read-only, and the default or custom cluster endpoint of the PolarDB cluster becomes a read/write proxy endpoint of the ApsaraDB RDS for MySQL instance. In this case, the instance cannot be connected by using the new read/write endpoint because no read/write nodes exist in the instance. If you want the instance to be connected by using the proxy endpoint, you must go to the Database Proxy page of the instance in the ApsaraDB RDS console and set Read/Write Attribute of the endpoint to Read-only. When you perform migration rollback, you must manually change the read/write attribute back to Read/Write to allow the instance to be connected by using the rolled-back endpoint.

Step 3: Complete the migration

1. Log on to the PolarDB console.

2. Find the cluster and click the cluster ID.

3. In the RDS Migration section of the Basic Information page, click Complete Migration. In the dialog box that appears, click OK.

   Note

   • After you click OK, the system stops data synchronization within approximately 2 minutes. During this process, the migration status is Disable 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 you disable the binary logging feature, write performance can be slightly improved. However, the PolarDB cluster is automatically restarted.

   • If you no longer need the source ApsaraDB RDS instance, you can release or unsubscribe from the instance. For more information, see (Optional) Release or unsubscribe from an ApsaraDB RDS instance.

   • If you want to renew or change the configuration of the source ApsaraDB RDS instance, click Complete Migration.

(Optional) Release or unsubscribe from an ApsaraDB RDS instance

After data is migrated from the source ApsaraDB RDS instance to the PolarDB cluster, you can release or unsubscribe from the instance if services run on the cluster as expected and the instance is no longer required.

• You can unsubscribe from ApsaraDB RDS instances that use the subscription billing method. For more information, see Unsubscribe from a subscription primary RDS instance.

• Release ApsaraDB RDS instances that use the pay-as-you-go billing method at the earliest opportunity to save RDS resources. For more information, see Release or unsubscribe from an ApsaraDB RDS for MySQL instance.

(Optional) View the details of a data synchronization task (only for logical migration)

During the process of using logical migration for upgrade, if you encounter migration errors (such as a precheck failure) or other exceptions (such as high replication delay), you can go to the details page of the data synchronization task to view specific information about the task.

1. Log on to the PolarDB console.

2. Find the target cluster and click its ID.

3. In the RDS Migration section of the Basic Information 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.

   

5. During the migration process, if you want to adjust the synchronization objects of the synchronization task, you can click Reselect Objects. For example, the source ApsaraDB RDS for MySQL instance may have new databases that also need to be included for the synchronization task.

(Optional) Roll back the migration

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 original state before the data migration. After the rollback, the read/write state of the source ApsaraDB RDS for MySQL 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 ApsaraDB RDS for MySQL instance to the PolarDB cluster.

1. Log on to the PolarDB console.

2. Find the cluster and click its ID.

3. In the RDS Migration section of the Basic Information page, click Roll Back Migration.

4. In the Start Switchback dialog box, select Switch Back with Endpoints (Connection Changes Not Required) or Switch Back without Endpoints (Connection Changes Required).

   • Switch Back with Endpoints (Connection Changes Not Required):

     1. If you select Switch Back with Endpoints (Connection Changes Not Required), the system interchanges the endpoints between the ApsaraDB RDS for MySQL instance and the PolarDB cluster. You do not need to modify the configurations of your application to connect to the PolarDB cluster.

     2. Click OK. After the rollback, the read/write state of the source ApsaraDB RDS for MySQL 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 ApsaraDB RDS for MySQL instance to the PolarDB cluster.

   • Switch Back without Endpoints (Connection Changes Required):

     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. After the rollback, the read/write state of the source ApsaraDB RDS for MySQL 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 ApsaraDB RDS for MySQL instance to the PolarDB cluster.

     3. Refresh the page. If the value of Source RDS Read/Write Status becomes Read/Write, change the database endpoint in your application to the endpoint of the ApsaraDB RDS for MySQL instance at the earliest opportunity.