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

Migration type

Scenario

Migrate from a single zone to another single zone

The zone where the instance resides is at full capacity or has other issues that affect instance performance.

Migrate from a single zone to multiple zones

After the migration, the primary and secondary instances reside in different zones to implement cross-data center disaster recovery.

Compared with single-zone deployment, multi-zone deployment provides a higher level of disaster recovery. For example, a single-zone instance can withstand server and rack failures, whereas a multi-zone instance can withstand data center failures.

Migrate from multiple zones to a single zone

To meet the requirements of specific features.

Category

Description

Before migration

• Loss of host environment: The migration involves moving the instance across hosts. This clears the host account and any programs or files, such as SSIS, SSAS, and SSRS, deployed on the original host. Back up or migrate your data in advance.

  Important

  RDS for SQL Server leverages the native Microsoft SQL Server kernel to provide a reliable and efficient managed database service. When your business requirements include the use of functionalities like SSIS, SSAS, and SSRS, a greater degree of professional operational capability is demanded from you to guarantee business continuity.

• Avoid metadata modifications: During the zone migration, do not perform operations such as adding or deleting databases or changing the recovery model. Otherwise, data inconsistency may occur.

• Migration cannot be canceled: After a migration task starts, it cannot be canceled. Proceed with caution.

• Perform migration during off-peak hours: The time required for migration depends on the data volume of the instance and is typically about 20 minutes. Many operations during the migration may prolong the process. Perform the migration during off-peak hours.

• Ensure an automatic reconnection mechanism: During the switchover, the instance is unavailable for a few minutes. This causes a transient connection interruption. Make sure your application has an automatic reconnection mechanism.

• Check the endpoint: After the migration, the virtual IP address (VIP) changes. Make sure your application uses the instance endpoint instead of the IP address for access.

  For clients that use a Java virtual machine (JVM), set the time-to-live (TTL) to 60 seconds or less. This ensures that if the VIP of the endpoint changes, the application can query DNS again to receive and use the new VIP of the resource.

  Methods to set the TTL in a JVM

  • To set the TTL for all applications that use the JVM: in the $JAVA_HOME/jre/lib/security/java.security file, set the value of the networkaddress.cache.ttl parameter to 60.

  • To set the TTL for only a local application, set java.security.Security.setProperty("networkaddress.cache.ttl" , "60"); in the application's initialization code before the first call to InetAddress.getByName(), that is, before any network connection is established.

• Plan for DTS tasks: If a Data Transmission Service (DTS) task is running, plan ahead. You must manually restart the task after the migration is complete.

• Normal service access: The migration process involves data relocation. During this time, the ApsaraDB RDS for SQL Server instance remains accessible, and your services are not affected.

After migration

• Verify configuration consistency: The instance name, port, tags, and database accounts remain unchanged after the migration. Verify that these configurations are normal.

• Clear the DNS cache: Promptly clear the client-side DNS cache to prevent connection failures caused by the cache.

• Verify the connection: Use the endpoint to verify that the instance is accessible and that your services function as expected.

• Restart DTS tasks: If any DTS tasks were running before the migration, manually restart them to ensure they run properly.