Cross-zone migration moves an ApsaraDB RDS for MySQL instance to a different zone within the same region, without data loss. Migration takes up to one hour for cloud disk instances and several hours for Premium Local SSD instances, depending on the amount of data.
Limitations
Before starting, confirm that your instance meets all of the following conditions:
The instance runs High-availability Edition or Basic Edition. Serverless instances are not supported.
The instance does not use a phased-out instance type. See Instance types for standard primary ApsaraDB RDS for MySQL instances (original x86 architecture). To change the instance type, see Change instance specifications.
The instance is in the Running state. If the instance has read-only instances, those must also be in the Running state — otherwise the
OperationDenied.MasterDBlnstancestateerror appears when you start the migration.If the instance uses cloud disks, the minor engine version is 20201031 or later. To update, see Update the minor engine version.
The region contains multiple zones. See Regions and zones.
The shared database proxy is disabled. To check: on the Database Proxy page, look for the Read/Write Splitting (Shared) tab. If the tab appears, the shared proxy is enabled.
Shared database proxies are no longer maintained as of April 1, 2021. If you still use one, upgrade to a dedicated database proxy. See Upgrade the database proxy from a shared database proxy to a dedicated database proxy. Dedicated and general-purpose database proxies are not affected by cross-zone migration.
If the instance uses Premium Enterprise SSDs (ESSDs) with Buffer Pool Extension (BPE) enabled, the destination zone must support BPE. See Applicable scope. To migrate to a zone without BPE support, disable BPE first.
Billing
Cross-zone migration is free of charge, including single-zone to multi-zone migrations.
Migration impacts
Instance switchover
A switchover may occur during migration, making the primary instance endpoint and database proxy endpoint temporarily unavailable. Configure your application to reconnect automatically. If it is not configured for auto-reconnect, reconnect manually.
A switchover occurs when either of the following conditions is met:
| Condition | Effect |
|---|---|
| The destination zone of the primary instance differs from its current zone | The primary instance is replaced during migration |
| The destination zone of the primary instance differs from its current network zone | The primary instance is replaced during migration |
For details on switchover behavior, see Impacts of an instance switchover.
VIP change
If a switchover occurs, the virtual IP address (VIP) of the instance changes while the endpoint remains the same. Connect your application using the endpoint, not the IP address.
PolarDB-X 1.0 attachment: A VIP change may break connectivity between the RDS instance and the attached PolarDB-X 1.0 instance. Fix any connectivity issues promptly. See Fix database shard connections.
DNS cache: Delete cached Domain Name System (DNS) records from the database client immediately after migration. For JVM clients, set the time-to-live (TTL) to 60 seconds or less so the client re-resolves the endpoint after a VIP change. For more information about how to set the TTL in the JVM configuration, see Class InetAddress.
Other impacts
| Impact | Details |
|---|---|
| DTS tasks | Restart any ongoing Data Transmission Service (DTS) tasks after migration completes. See What is DTS? |
| Table recreation | Tables are recreated during migration. The CREATE_TIME field in INFORMATION_SCHEMA reflects the new creation time. |
| Resource availability | If the destination zone has insufficient resource inventory, migration may fail. |
| vSwitch-only change | You cannot change only the vSwitch during cross-zone migration. To change the vSwitch, see Change the VPC and vSwitch. |
Migration scenarios
You can only migrate within the same region. To move to a different region, create an RDS instance in the target region, migrate data using DTS, verify your workloads, and then release the original instance.
The following migration scenarios are supported. Multi-zone deployment protects against data center failures; single-zone deployment protects only against server and rack failures.
| Scenario | Result | When to use |
|---|---|---|
| One zone to one zone | Primary and secondary instances reside in the same destination zone. Example: both in Singapore Zone C move to Singapore Zone A. | Choose this when you need to consolidate instances into a single zone. Note that single-zone deployment does not provide cross-zone disaster recovery (DR). |
| One zone to multiple zones | Primary and secondary instances reside in different destination zones. Example: primary moves from Singapore Zone C to Singapore Zone B; secondary moves to Singapore Zone A. | Choose this when you want cross-zone DR. Multi-zone deployment protects against data center failures. |
| Multiple zones to one zone | Primary and secondary instances move to the same destination zone. Example: primary in Singapore Zone B and secondary in Singapore Zone A both move to Singapore Zone C. | Choose this when simplifying your topology. Note that cross-zone DR is lost. |
| Multiple zones to multiple zones | Primary and secondary instances move to different destination zones. Example: primary moves from Singapore Zone B to Singapore Zone A; secondary moves from Singapore Zone C to Singapore Zone B. | Choose this to change zone placement while keeping cross-zone DR. |
Migrate an instance across zones
Make sure a virtual private cloud (VPC) and at least one vSwitch exist in the destination zone before you start. If not, create a vSwitch in the destination zone first.
Log on to the ApsaraDB RDS console. In the top navigation bar, select the region of the instance. Find the instance and click its ID.
On the Basic Information page, click Migrate Data Across Zones in the upper-right corner.
If Migrate Data Across Zones is not displayed, check whether the instance meets all the limitations listed above.
In the Migrate Instance Across Zones dialog box, set the Destination Zone parameter and select a vSwitch. Then set the Switching Time parameter: Click Yes.
Switch Immediately — the switchover happens as soon as migration completes.
Switch Within Maintenance Window — the switchover is deferred to the next maintenance window.
ImportantAfter the switchover, if the vSwitch changed, the instance reconnects over new connections. Make sure your application reconnects automatically. If cached DNS records are not updated immediately, a second switchover may occur approximately 10 minutes later as traffic redirects to the destination primary zone. Configure your application to reconnect automatically. For more information, see Impacts of an instance switchover.
In the confirmation dialog box, review the zone information before and after migration, then click OK.
FAQ
If data is written to the instance during migration, is the original data affected after the switchover? Is the newly written data retained?
Original data is not affected, and newly written data is retained. An instance switchover occurs during migration — configure your application to reconnect automatically. See Impacts of an instance switchover.
What affects migration time?
For Premium Local SSD instances, migration time depends on the amount of data — large datasets can take several hours. For cloud disk instances, migration takes up to one hour.
API reference
| Operation | Description |
|---|---|
| MigrateToOtherZone | Migrates an instance across zones |
What's next
For cross-zone migration of other database engines in the same region, see: