PolarDB for MySQL lets you move a cluster's compute nodes to a different zone without changing its endpoints. Use this to optimize latency for co-located Elastic Compute Service (ECS) instances, run disaster recovery drills, or rebalance zone distribution.
Choose an operation
Three operations are available. Pick the one that matches your goal:
| Goal | Operation | Data migration | Service interruption |
|---|---|---|---|
| Move the cluster to a zone where your ECS instances are, or run a disaster recovery drill when the target is already a secondary zone | Change the primary zone | No (compute nodes only, ~5 min per node) | 1–2 transient connections, ~30s each |
| Move the cluster to a zone where your ECS instances are, when the target is not a secondary zone | Change the primary zone | Yes (duration depends on data volume) | 1–2 transient connections, ~30s each |
| Rebalance secondary zone placement | Change the secondary zone | Yes (duration depends on data volume) | — |
| Perform a primary/secondary switchover to the hot standby storage cluster | Switch to the hot standby storage cluster | No | 1–2 transient connections, ~30s each |
Prerequisites
Before you begin, make sure that:
Resources in your region are deployed across two or more zones. Multi-zone deployment is unavailable in the following regions: Philippines (Manila), South Korea (Seoul), China (Qingdao), China (Chengdu), China (Hohhot), and Thailand (Bangkok).
For hot standby storage cluster switchover: the hot standby storage cluster feature is enabled on your cluster. See High-availability mode (hot standby storage cluster).
Change the primary zone
Changing the primary zone migrates the cluster's compute nodes to the destination zone. The primary endpoint and cluster endpoints remain unchanged after the operation, but the vSwitch and IP address may change.
Schedule this operation during off-peak hours. One or two transient connections occur during the switchover, each lasting approximately 30 seconds. Make sure your application can automatically reconnect to the database.
If the destination zone is not a current secondary zone, data migration is required. Migration time depends on data volume and may take several hours for large datasets. Proceed with caution.
Log on to the PolarDB console.
In the upper-left corner, select the region where the cluster is deployed.
Find the cluster and click its ID.
At the bottom of the Basic Information page, click Migrate Cluster Across Zones.
In the dialog box, configure the following parameters:
Parameter Description Destination Zone The target zone for the cluster. If the zone is already a secondary zone, only compute nodes are migrated (~5 min per node). Otherwise, data migration is required. Destination VPC The VPC in the destination zone. Destination vSwitch The vSwitch in the destination VPC. If no vSwitches are available, create one first. See Create and manage a vSwitch. Validity Period Set to Immediately to run at once, or Upgrade in Maintenance Window to schedule during the maintenance window. To view or cancel a scheduled task, see Scheduled tasks. Click OK.
Change the secondary zone
Changing the secondary zone migrates data from the original secondary zone to the destination zone. The destination zone cannot be the current primary or secondary zone.
Data migration is always required when changing the secondary zone. Migration time depends on data volume and may take several hours for large datasets. Schedule this operation during off-peak hours.
Log on to the PolarDB console.
In the upper-left corner, select the region where the cluster is deployed.
Find the cluster and click its ID.
In the left-side navigation pane, choose Settings and Management > Service Availability.
On the Service Availability page, click Change Secondary Zone.
In the dialog box, select the destination zone and configure the Effective Time parameter:
Effective Immediately: Runs the operation immediately.
Effective in Maintenance Window: Schedules the operation during the maintenance window. To view or cancel a scheduled task, see Scheduled tasks.
Click OK.
Switch to the hot standby storage cluster
This operation performs a primary/secondary switchover to the hot standby storage cluster. After the switchover, the primary endpoint, cluster endpoint, vSwitch, and IP address remain unchanged, but indirect accesses may occur. Proceed with caution.
Avoid switching between the primary cluster and the hot standby storage cluster frequently. Frequent switching can cause high replication latency.
This operation is supported for Standard Edition and Cluster Edition clusters only. You can switch over to the hot standby storage cluster only — switching to a non-secondary zone is not supported.
Log on to the PolarDB console.
In the upper-left corner, select the region where the cluster is deployed.
Find the cluster and click its ID.
In the left-side navigation pane, choose Settings and Management > Service Availability.
On the Service Availability page, click Switch Over to Hot Standby Storage Cluster.
Click OK.
FAQ
Does changing the primary zone cause extended service downtime?
No. The migration time (5 minutes per compute node, or hours for data migration) is not service downtime. Only one or two transient connections occur during the actual switchover, each lasting approximately 30 seconds. Schedule the change during off-peak hours and make sure your application reconnects automatically.
What happens to my endpoints after changing the primary zone?
The primary endpoint and cluster endpoints remain unchanged, so existing connections continue to work. The vSwitch and IP address may change, which can briefly affect availability. Plan the change during a maintenance window to minimize impact.