You can migrate an RDS instance to a different zone within the same region. After the migration, the properties, configurations, and endpoints of the instance remain unchanged. The migration time depends on the instance's data volume and can take several hours.
Prerequisites
You can perform a cross-zone migration only if the instance's region has multiple zones. For more information, see Regions and zones.
The instance must be a primary instance without any read-only instances.
The instance must be running.
This feature is not supported for RDS instances that run RDS Cluster Edition.
Limitations
For an instance that uses Premium Local SSDs, you can migrate only its primary zone.
Cross-zone migration is not supported for serverless instances.
If the instance uses Performance Level (PL) cloud disks as the storage type and Buffer Pool Extension（BPE） is enabled, you cannot migrate the instance to a zone that does not support I/O acceleration. For information about regions and zones that support I/O acceleration, see Supported regions and zones.
You can disable I/O acceleration and then perform the cross-zone migration.
Billing
Cross-zone migration is free, even when migrating an instance from a single zone to multiple zones.
If your instance uses a standard SSD, the migration automatically upgrades its storage type to PL1 ESSD. After the upgrade, storage fees remain unchanged.
Impacts
The switchover briefly affects instance availability. Ensure that your application has an automatic reconnection mechanism.
The virtual IP (VIP) address changes during a cross-zone migration. Use the instance endpoint, not the IP address, to connect your application to the instance.
If a switchover between the primary and secondary instances occurs during the migration, the virtual IP (VIP) address changes. Use the instance endpoint instead of its IP address, and promptly clear the client-side DNS cache. For applications that run on a Java Virtual Machine (JVM), set the DNS cache TTL to 60 seconds or less. This ensures that the application can resolve the new VIP address when it changes.
NoteFor information about how to set the TTL in a JVM, see the Oracle documentation for Class InetAddress.
After the cross-zone migration is complete, you must restart any running DTS tasks.
If the destination zone has insufficient resources, the cross-zone migration may fail.
ApsaraDB RDS for PostgreSQL no longer supports the purchase of new instances that use standard SSDs. If your RDS instance uses a standard SSD, the cross-zone migration automatically upgrades its storage type to PL1 ESSD. For more information, see [EOS/Discontinuation] The standard SSD storage type is discontinued for specific database engines in ApsaraDB RDS from July 01, 2022.
Migration types
Migration type | Use case |
From a single zone to another zone | The instance's current zone is overloaded or has other issues affecting performance. |
From a single zone to multiple zones | This migration type deploys the primary and secondary instances in different zones to implement cross-zone disaster recovery. A multi-zone deployment can withstand higher-level disasters, such as a data center failure. Note For an instance with primary and secondary nodes, we recommend migrating it to a multi-zone deployment to implement cross-zone disaster recovery. |
From multiple zones to a single zone | To meet the requirements of specific features. |
Procedure
Go to the Instances page. In the top navigation bar, select the region in which the RDS instance resides. Then, find the RDS instance and click the ID of the instance.
In the Basic Information section, click Migrate Data Across Zones.
In the dialog box that appears, select the destination primary and secondary zones and their vSwitches, and then click Yes.
The following table describes the parameters.
Parameter
Description
Configure Primary Zone
Select the new primary and secondary zones.
For an instance that uses Premium Local SSDs, you can migrate only the primary zone.
For instances with cloud disks, you can migrate both the primary and secondary zones, or just one of them. Examples:
You can migrate an instance from Singapore Zone A (primary) + Zone B (secondary) to Singapore Zone C (primary) + Zone D (secondary).
You can migrate an instance from Singapore Zone A (primary) + Zone B (secondary) to Singapore Zone A (primary) + Zone C (secondary).
NoteIf you migrate only one zone, you need to configure only the zone that you want to migrate.
Configure Secondary Zone
vSwitch in Primary Zone
Select the vSwitches for the primary and secondary zones. If no vSwitch is available in the current zone, see Create a vSwitch.
vSwitch in Secondary Zone
Switching Time
Switch Now: The switchover is performed immediately after you submit the request.
Switchover Within Maintenance Window: The switchover is performed within the specified maintenance window. For more information, see Set a maintenance window.
Take Effect at Specified Time Range: You can specify a time for the switchover.
After you click Yes, the system starts to copy data to the destination zone. This process does not affect the running instance. After the data is copied, the system switches traffic to the new connection based on the time that you selected for Switch Now: Switchover Within Maintenance Window, Take Effect at Specified Time Range, or Take Effect at Specified Time Range.
WarningThe switchover causes a transient connection failure. Make sure your application has an automatic reconnection mechanism. Otherwise, you must reconnect manually.
Because the client-side DNS cache may not be immediately refreshed, some traffic might be switched up to 10 minutes later, causing a second transient connection failure. For applications that use a JVM, set the TTL in the JVM configuration to 60 seconds or less. This ensures that when the VIP address of the endpoint changes, the application can re-query DNS to retrieve and use the new VIP address. For instructions on how to set the TTL, see the Impacts section of this topic.
API reference
API | Description |
Migrates an RDS instance across zones. |