ApsaraDB RDS:Perform cross-zone migration

For more information about how to migrate an RDS instance that runs a different database engine across zones in the same region, see the following topics:

• Migrate an ApsaraDB RDS for PostgreSQL instance across zones in the same region

• Migrate an ApsaraDB RDS for SQL Server instance across zones in the same region

Billing rules

You are not charged for the cross-zone migration. This applies even if you migrate your RDS instance from one zone to multiple zones.

Impacts

• Instance switchover: During the cross-zone migration, an instance switchover may be triggered. As a result, the endpoint of the primary RDS instance and the database proxy endpoint become unavailable for a short period of time. Make sure that your application is configured to automatically reconnect to your RDS instance. If the application is not configured to automatically reconnect to the RDS instance, you must manually connect the application to the RDS instance. For more information, see Impacts of an instance switchover. The following list describes the scenarios in which an instance switchover is triggered:

  • If the destination zone of the primary RDS instance is different from the current zone of the primary RDS instance, the primary RDS instance is changed during the cross-zone migration.

  • If the destination zone of the primary RDS instance is different from the current network zone of the primary RDS instance, the primary RDS instance is changed during the cross-zone migration.

• VIP change: If an instance switchover occurs during the cross-zone migration, the virtual IP address (VIP) of your RDS instance is changed. We recommend that you use an endpoint rather than an IP address of your RDS instance to connect your application to your RDS instance.

  • If your RDS instance is attached to a PolarDB-X 1.0 instance, VIP changes may affect the connectivity between the RDS instance and the PolarDB-X 1.0 instance. We recommend that you fix connectivity issues at the earliest opportunity. For more information, see Fix database shard connections.

  • After the migration, you must immediately delete the cached Domain Name System (DNS) records from the database client. If the database client runs on a JVM, we recommend that you set the time-to-live (TTL) in the JVM configuration to 60 seconds or less. In this case, if the virtual IP address that is bound to the in-use endpoint of your RDS instance changes, your application can query the related DNS records again to obtain the new virtual IP address. Then, your application can connect to the new virtual IP address.

    Note

    For more information about how to set the TTL in the JVM configuration, see Class InetAddress.

• Interruption of DTS tasks: If the RDS instance has an ongoing Data Transmission Service (DTS) task, you must restart the task after the cross-zone migration is complete. For more information, see What is DTS?

• Recreation of tables: A table is recreated when you perform the cross-zone migration. As a result, the creation time of the table is changed, and the value of the CREATE_TIME field in the INFORMATION_SCHEMA table is changed.

• If the resource inventory in the zone to which you want to migrate your RDS instance is insufficient, the migration may fail.

• During the cross-zone migration, you cannot change only the vSwitch. For more information about how to change the vSwitch of an RDS instance, see Change the VPC and vSwitch.

Procedure

1. Log on to the ApsaraDB RDS console and 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 instance ID.

2. On the Basic Information page, click Migrate Data Across Zones in the upper-right corner.

   Note

   If Migrate Data Across Zones is not displayed, you must check whether your RDS instance meets the prerequisites.

3. In the Migrate Instance Across Zones dialog box, configure the Destination Zone parameter, select a vSwitch, and configure the Switching Time parameter. Then, click Yes.

   Migration scenario	Description
   Migration from one zone to another zone	The primary and secondary RDS instances reside in the same destination zone. For example, the primary RDS instance and the secondary RDS instance reside in Singapore Zone C, and you migrate the instances to Singapore Zone A.
   Migration from one zone to multiple zones	The primary and secondary RDS instances reside in different destination zones. For example, the primary RDS instance and the secondary RDS instance reside in Singapore Zone C, and you migrate the primary RDS instance to Singapore Zone B and the secondary RDS instance to Singapore Zone A. Note After the cross-zone migration, the primary and secondary RDS instances reside in different zones to achieve cross-zone disaster recovery (DR). The multi-zone deployment method delivers higher disaster recovery capabilities than the single-zone deployment method. If you select the single-zone deployment method, your database system can withstand server and rack failures. If you select the multi-zone deployment method, your database system can withstand data center failures. If your database system contains primary and secondary RDS instances, we recommend that you migrate your RDS instance to multiple zones to implement cross-zone DR.
   Migration from multiple zones to one zone	The primary and secondary RDS instances reside in the same destination zone. For example, the primary RDS instance resides in Singapore Zone B, the secondary RDS instance resides in Singapore Zone A, and you migrate the RDS instances to Singapore Zone C. Note If you select the single-zone deployment method, your database system cannot achieve cross-zone DR. We recommend that you migrate the RDS instances to different zones.
   Migration from one zone to multiple zones	The primary and secondary RDS instances reside in different destination zones. For example, the primary RDS instance resides in Singapore Zone B, the secondary RDS instance resides in Singapore Zone C, and you migrate the primary RDS instances to Singapore Zone A and the secondary RDS instance to Singapore Zone B.

   Important

   • After the cross-zone migration, the system switches your workloads based on the value of the Switching Time parameter. You can set the Switching Time parameter to Switch Immediately or Switch Within Maintenance Window. If the vSwitch of the RDS instance is changed during the switchover, the RDS instance is connected over new connections. Make sure that your application is configured to automatically reconnect to the RDS instance. Otherwise, you must manually reconnect your application to the RDS instance.

   • If the DNS records cached on the database client are not immediately updated after the migration, some workloads may be switched over to the destination primary zone 10 minutes later. As a result, the RDS instance encounters another instance switchover. Make sure that your application is configured to automatically reconnect to the RDS instance. Otherwise, you must manually reconnect your application to the RDS instance.

   • For more information about the impacts of an instance switchover, see Impacts of an instance switchover.

4. In the Migrate Instance Across Zones dialog box, confirm the zone information before and after the migration and click OK.

Related operations

FAQ

• If data is written to my RDS instance during cross-zone migration, is original data on the RDS instance affected after the workload switchover? Is the newly written data retained?

  Original data is not affected, and the newly written data is retained.

  Important

  An instance switchover occurs during the migration. Make sure that your application is configured to automatically reconnect to the RDS instance. Otherwise, you must manually reconnect your application to the RDS instance. For more information about the impacts of an instance switchover, see Impacts of an instance switchover.

• What factors affect the time that is required for cross-zone migration?

  The time that is required for cross-zone migration varies based on the amount of data on your RDS instance. If a large amount of data exists on the RDS instance, a long period of time is required. If the RDS instance uses local disks, several hours are required. If the RDS instance uses cloud disks, up to one hour is required.