PolarDB:Change the primary zone and vSwitch of a cluster

Scenarios and usage notes

This feature is suitable for disaster recovery and scenarios in which you want to use an Elastic Compute Service (ECS) instance to connect to the PolarDB cluster node in the nearest zone.

• When services are switched from the primary zone to a secondary zone, one or two transient connections occur. Each transient connection lasts approximately 30s. We recommend that you perform the switchover during off-peak hours and make sure that your application can automatically reconnect to the database service.

• If the destination zone is a secondary zone, data migration is not required. The system migrates only the compute nodes. This way, only an average of 5 minutes is required to migrate each compute node across data centers. In most cases, this operation is performed in disaster recovery drills.

• If the destination zone is not a secondary zone, the data in the cluster must be migrated. The time required to migrate data varies based on the volume of the data. If the volume of your data is excessively large, several hours may be required. Proceed with caution. In most cases, this operation is performed to adjust the layout of applications and databases distributed among zones. This way, applications can access databases from the nearest zone.

• After the primary zone is changed, the primary endpoint and the cluster endpoint of the cluster remain unchanged, but the vSwitch and IP address may be changed. This operation may affect the availability of the databases. Proceed with caution.

• Available resources are deployed in two or more zones within the region of the PolarDB for MySQL cluster. The multi-zone deployment feature is not available in the following regions: Philippines (Manila), South Korea (Seoul), Australia (Sydney), China (Qingdao), China (Chengdu), China (Hohhot), and Thailand (Bangkok).

Procedure

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. Find the cluster and click the cluster ID.

4. On the Overview page, click Migrate Cluster Across Zones.

   

5. In the dialog box that appears, specify Target Zone and Target VSwitch, and configure Effective Time based on your business requirements.

   

   Note

   • If the destination zone is a secondary zone, data migration is not required. The system migrates only the compute nodes. This way, only an average of 5 minutes is required to migrate each compute node across data centers. In most cases, this operation is performed in disaster recovery drills.

   • If the destination zone is not a secondary zone, the data in the cluster must be migrated. The time required to migrate data depends on the volume of the data. Several hours may be required to migrate the data. Proceed with caution. In most cases, this operation is performed to adjust the layout of applications and databases distributed among zones so that applications can access databases from the nearest zone.

   • If no vSwitches are available in the destination zone, you must create a vSwitch. For more information, see Create a vSwitch.

   • You can set Effective Time to Apply Immediately or Upgrade in Maintenance Window. If you select Upgrade in Maintenance Window, you can view the details about the scheduled task or cancel the task on the Scheduled Tasks page. For more information, see View or cancel a scheduled task.

6. Click OK.

FAQ

• How much time is required to change the primary zone for a cluster?

• • If the destination zone is a secondary zone, data is not migrated. The system migrates only the compute nodes. This way, only an average of 5 minutes is required to migrate each compute node across data centers. In most cases, this operation is performed in disaster recovery drills.

  • If the destination zone is not a secondary zone, the data in the cluster must be migrated. The time required to migrate data varies based on the volume of the data. If the volume of your data is excessively large, several hours may be required. Proceed with caution. In most cases, this operation is performed to adjust the layout of applications and databases distributed among zones. This way, applications can access databases from the nearest zone.

  

• Is the time required to change the primary zone equal to the service downtime? For example, I want to use a secondary zone as the primary zone for a four-node cluster. The average time required to migrate a node is 5 minutes. In this case, are my services unavailable for approximately 20 minutes?

  No, the time required to change the primary zone is not equal to the service downtime. Only one or two transient connections occur. Each transient disconnection lasts approximately 30s. We recommend that you change the primary zone during off-peak hours and make sure that your applications can be automatically reconnected to the cluster.

• How does the system ensure that the cluster runs as expected when the primary zone is being changed?

  After you change the primary zone for a cluster, the primary endpoint and cluster endpoint of the cluster remain unchanged. Therefore, you can still use these endpoints to connect to the cluster. However, the vSwitch and IP address of the cluster may change. This operation may affect the availability of the databases. Proceed with caution.