PolarDB for MySQL allows you to deploy a cluster across multiple zones. Compared with single-zone clusters, multi-zone clusters provide better disaster recovery capabilities and can withstand data center-level faults. 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 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 architecture.

Architecture

Billing

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

Establish a multi-zone architecture

If the prerequisites are met, a multi-zone cluster is created by default when you create a PolarDB for MySQL cluster.

The existing single-zone clusters are upgraded to multi-zone clusters. The upgrades are automatically completed by migrating data online, and your business is not affected.

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 resides.
  3. Find the cluster, and then click the cluster ID.
  4. On the Overview page, view Zones.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 database cluster to a different zone. This is applicable to scenarios, such as disaster recovery or when an Elastic Compute Service (ECS) instance is required to access the cluster in a nearby zone. 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 resides.
  3. Find the cluster, and then 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.
    Dialog box
    Note
    • If the destination zone is a secondary zone, data migration is not required. The zone can be rapidly switched across data centers because the system needs to migrate only the compute nodes of the database. The average time required to migrate a compute node is 5 minutes. This operation is often performed in disaster recovery drills.
    • If the destination zone is not a secondary zone, data must be migrated. The time required for the system to migrate data depends on the volume of the data. It may take several hours to migrate the data. Proceed with caution. This operation is often used to adjust the distribution of zones of applications and databases so that nearby database access can be achieved.
    • If no vSwitch is available in the destination zone, you must create a vSwitch first. For more information, see Create a vSwitch.
  6. Click OK.
    Notice After the primary zone is changed, the endpoints (cluster endpoints and primary endpoints) that are used to connect to databases remain unchanged. However, the vSwitch and the IP address may be changed. This operation may affect the database availability. Proceed with caution.

FAQ

  • Q: How long does it take to change the primary zone?
    • A: If the destination zone that you select is a secondary zone, you do not need to migrate data when you change the primary zone. The zone can be rapidly switched across data centers because the system needs to migrate only the compute nodes of the database. The average time required to migrate a compute node is 5 minutes. This operation is often performed in disaster recovery drills.
    • If the destination zone that you select is not a secondary zone, you must migrate data when you change the primary zone. The time required for the system to migrate data depends on the volume of the data. It may take several hours to migrate a huge volume of data. Proceed with caution. This operation is often used to adjust the distribution of zones of applications and databases so that nearby database access can be achieved.
    1
  • Q: Is the time required to change the primary zone equal to the unavailable time of services? For example, if a secondary zone needs to change to the destination primary zone, the average time required to migrate a node is 5 minutes. If a cluster has four nodes, does this mean that the service is unavailable for about 20 minutes?

    A: The time required to change the primary zone is not equal to the unavailable time of services. During the entire switchover process, one or two transient connection errors occur and last for about 30 seconds during only the primary/secondary switchover. We recommend that you change the primary zone during off-peak hours and make sure that your applications can automatically reconnect to the cluster.

  • Q: How do clusters run as expected when the primary zone is changed?

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