PolarDB for MySQL allows you to deploy a cluster across multiple zones. Compared with single-zone clusters, multi-zone clusters can enhance disaster recovery capabilities and withstand the breakdown of an entire data center. This topic describes how to deploy a cluster across multiple zones and change the primary zone.

Prerequisites

  • The region contains at least two zones.
  • The destination zone has sufficient computing resources.

Multi-zone deployment architecture

When a multi-zone cluster is deployed, data is distributed across zones. Compute nodes must be deployed in the primary zone. PolarDB reserves sufficient resources in a secondary zone to implement a failover if the primary zone fails. The following figure shows the multi-zone deployment architecture.

Architecture

Pricing

No additional fee is charged for multi-zone deployment.
Note You can upgrade a single-zone cluster to a multi-zone cluster for free.

Establish a multi-zone deployment architecture

By default, if the prerequisites are met, a multi-zone cluster is created. For more information about how to create a cluster, see Purchase a pay-as-you-go cluster.

The existing single-zone clusters are upgraded to multi-zone clusters. The upgrades are automatically performed by migrating data dynamically. This does not affect your services.

View the zones of a cluster

  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. Find the cluster and click the cluster ID.
  4. On the Overview page, view the Zones section. Zones

Change the primary zone

PolarDB allows you to change the primary zone. You can use this feature to migrate the compute nodes of a cluster to another zone. This is applicable to diverse scenarios. For example, you can use this feature when you perform disaster recovery or enable nearby access for Elastic Compute Service (ECS) instances. Change the primary zone
  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. Find the cluster and click the cluster ID.
  4. On the Overview page, click Migrate Cluster Across Zones.
    Migrate a cluster across zones
  5. In the dialog box that appears, specify Target Zone and Target VSwitch, and set Effective Time based on your business requirements.
    Dialog box
    Note
    • If the destination zone is a secondary zone, data migration is not required. The system needs to migrate only compute nodes and it requires an average of 5 minutes to migrate each compute node. Therefore, this operation is commonly performed in disaster recovery drills.
    • If the destination zone is not a secondary zone, data must be migrated. The time required to migrate data depends on the volume of the data. It may require several hours to migrate the data. Proceed with caution. This operation is typically performed to change the zones where applications and databases are deployed. This enables applications to access the nearby databases.
    • If no vSwitch is available in the destination zone, you must first create one. 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 also view the details of the scheduled task or cancel the task on the Scheduled Tasks page. For more information, see View or cancel a scheduled task.
  6. In the message that appears, click OK.
    Notice After the primary zone is changed, the endpoints (cluster endpoints and the primary endpoint) that are used to connect to databases remain unchanged. However, the vSwitch and the IP address may be changed. This operation may adversely affect the availability of the database. Proceed with caution.

FAQ

  • How long does it require to change the primary zone?
    • If the destination zone is a secondary zone, data migration is not required. The system needs to migrate only compute nodes and it requires an average of 5 minutes to migrate each compute node. Therefore, this operation is commonly performed in disaster recovery drills.
    • If the destination zone is not a secondary zone, data migration is required when you change the primary zone. The time required to migrate data depends on the volume of the data. It may require several hours to migrate a large volume of data. Proceed with caution. This operation is typically performed to change the zones where applications and databases are deployed. This enables applications to access the nearby databases.
    1
  • Is the time required to change the primary zone equal to the service downtime? For example, if you want to change a secondary zone to the primary zone, the average time required to migrate a node is 5 minutes. If a cluster has four nodes, will the service be interrupted for about 20 minutes?

    The time required to change the primary zone is not equal to the service downtime. During the switchover process, the service may be interrupted one or two times only when the primary/secondary switchover is performed. Each interruption may last about 30 seconds. We recommend that you change the primary zone during off-peak hours and make sure that your applications can automatically reconnect to the cluster.

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

    After the primary zone is changed, the endpoints (cluster endpoints and the primary endpoint) that are used to connect to databases remain unchanged. Therefore, you can still use the endpoints to connect to the clusters. However, the vSwitch and IP address used by the cluster may be changed. This operation may adversely affect the availability of the database. Proceed with caution.