Migrate an ApsaraDB RDS for SQL Server instance across zones - ApsaraDB RDS

ApsaraDB RDS for SQL Server allows you to migrate your ApsaraDB RDS for SQL Server instance across zones in the same region. After your RDS instance is migrated, its attributes, configuration, and endpoints remain unchanged. The period of time that is required to complete the migration varies based on the amount of the data that needs to be migrated. In most cases, the migration requires approximately 30 minutes.

Prerequisites

The region to which your RDS instance belongs consists of multiple zones. For more information about the regions and zones, see Regions and zones.
Your RDS instance is a primary RDS instance, and no read-only RDS instances are attached to your RDS instance.
Your RDS instance is in the Running state.

Billing rules

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

Impacts

If you start a task to migrate an RDS instance across zones, you cannot cancel the task.
The configurations of your RDS instance, such as the name, endpoints, tags, and database accounts, remain unchanged after the migration.
The migration process triggers data migration. During the process, your RDS instance runs as expected, and the workloads on the RDS instance are not affected.
The period of time that is required to complete the migration varies based on the data volume of your RDS instance. In most cases, the migration requires approximately 20 minutes. If a large number of operations are performed during the migration, the period of time to complete the migration is prolonged. We recommend that you upgrade your RDS instance during an appropriate period of time.
During the switchover, your RDS instance becomes unavailable for a few minutes. Make sure that your application is configured to automatically reconnect to your RDS instance.
The migration causes changes to the virtual IP addresses (VIPs) of your RDS instance. We recommend that you use an endpoint of your RDS instance instead of an IP address to connect your application to your RDS instance.
After the migration is complete, you must immediately delete the cached 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. This way, if the VIP 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 VIP. Then, your application can connect to the new VIP.
Note The following TTL-setting methods are provided for reference:
- For all JVM-based applications: Set the networkaddress.cache.ttl parameter in the $JAVA_HOME/jre/lib/security/java.security file to 60.
- For local applications: Configure the networkaddress.cache.ttl java.security.Security.setProperty("networkaddress.cache.ttl" , "60"); setting in the initialization code of local applications. The configuration must be completed before you call the InetAddress.getByName() function for the first time to establish a network connection.
If your RDS instance is attached to a PolarDB-X instance, the changes in VIPs temporarily affect the availability of the PolarDB-X instance. You must refresh the page of the PolarDB-X console to view the connection information.
If your RDS instance has an ongoing Data Transmission Service (DTS) task, you must restart the DTS task after the migration is complete.

Limits

You cannot migrate the following RDS instances across zones:

RDS instances that use shared instance types. For more information, see Instance families.
RDS instances that use Bring Your Own License (BYOL).
Serverless RDS instances. For more information, see Overview.
RDS instances that reside in the classic network. For more information, see Change the network type of an ApsaraDB RDS for SQL Server instance.
RDS instances that are added to Active Directory (AD) domains. For more information, see Connect an ApsaraDB RDS for SQL Server instance to a self-managed domain.
RDS instances for which the Transparent Data Encryption (TDE), SSL encryption, or cloud disk encryption feature is enabled. For more information, see Configure TDE for an ApsaraDB RDS for SQL Server instance, Configure SSL encryption for an ApsaraDB RDS for SQL Server instance, or Configure the cloud disk encryption feature for an ApsaraDB RDS for SQL Server instance.
RDS instances for which the snapshot backup feature is enabled. For more information, see Enable the snapshot backup feature for an ApsaraDB RDS for SQL Server instance.
Read-only RDS instances and primary RDS instances on RDS Cluster Edition to which read-only RDS instances are attached. For more information, see Create a read-only ApsaraDB RDS for SQL Server instance.

Migration scenarios

Migration scenario	Description
Migration from one zone to another zone	The original zone in which your RDS instance resides cannot ensure service performance due to issues such as heavy loads.
Migration from one zone to multiple zones	You want the primary and secondary RDS instances reside in different zones to implement cross-zone disaster recovery. 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. Note 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 disaster recovery.
Migration from multiple zones to one zone	You want to use specific features that are supported only when the single-zone deployment method is used.

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 Across Zones.
In the dialog box that appears, specify the destination zone, VPC, vSwitch, and migration time.
Note
- For more information about how to create a VPC, see Create and manage a VPC.
- For more information about how to create a vSwitch, see Work with vSwitches.
Click OK.
After you click OK, the system starts to replicate the data of your RDS instance to the destination zones. This process does not interrupt the workloads on your RDS instance. After all data is replicated to the destination zone, the system switches the workloads over to the destination zone within the specified time period. You can set the switching time to Switch Now or Switch Within Maintenance Window.
Important During the switchover, your RDS instance becomes unavailable for a few minutes. Make sure that your application is configured to automatically reconnect to your RDS instance.

FAQ

Can I directly upgrade or change the deployment mode of an RDS instance that runs an SQL Server Web edition on RDS Basic Edition to the multi-zone deployment mode? Can the primary and secondary RDS instances reside in different zones?

No, you cannot change the deployment mode of your RDS instance that runs an SQL Server Web edition on RDS Basic Edition to the multi-zone deployment mode. You can upgrade your RDS instance to an instance that runs an SQL Server Standard edition on RDS High-availability Edition. Then, migrate the secondary RDS instance to another zone. For more information, see Upgrade the major engine version and RDS edition of an ApsaraDB RDS for SQL Server instance.

Note In RDS High-availability Edition, your database system consists of a primary RDS instance and a secondary RDS instance. For more information, see RDS High-availability Edition.

Related operations

Operation	Description
Migrate an instance across zones	Migrates an instance across zones.