Migrate to another zone

Migration type

Scenario

Migrate from one zone to another zone

The current zone is at full capacity or experiencing performance issues.

Migrate from one zone to multiple zones

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

Compared to single-zone instances, multi-zone instances tolerate higher-level failures. For example, single-zone instances withstand server- and rack-level failures, while multi-zone instances withstand data center-level failures.

Migrate from multiple zones to one zone

To meet specific feature requirements.

Category

Description

Before migration

• Host environment loss: Zone migration involves cross-host migration. This clears your host account and any programs or files deployed on the original host (such as SSIS, SSAS, SSRS). Back up or migrate this data beforehand.

  Important

  Alibaba Cloud RDS SQL Server uses the native Microsoft SQL Server kernel and provides stable, efficient managed database services. If your workload requires features like SSIS, SSAS, or SSRS, ensure you have professional O&M capabilities to maintain business continuity.

• Avoid metadata changes: Do not add or delete databases or change the recovery model during zone migration. These actions may cause data inconsistency.

• Migration cannot be canceled: Once started, migration cannot be canceled. Proceed with caution.

• Choose off-peak hours: Migration typically takes about 20 minutes, depending on your data volume. Heavy activity during migration may extend this time. Perform migration during off-peak business hours.

• Ensure automatic reconnection: The instance will be unavailable for a few minutes during switchover, briefly affecting availability. Ensure your application has a reconnection mechanism.

• Check connection address: The virtual IP address (VIP) changes after migration. Ensure your application uses the endpoint instead of a direct IP address to access the instance.

  For JVM-based clients, set the TTL to 60 seconds or less. This ensures your application receives the new VIP by requerying DNS when the endpoint’s VIP changes.

  Set TTL in JVM

  • For all JVM applications: Set the networkaddress.cache.ttl parameter to 60 in the $JAVA_HOME/jre/lib/security/java.security file.

  • For a specific local application: Before making any network connections—specifically, before the first call to InetAddress.getByName()—add this line to your application’s initialization code: java.security.Security.setProperty("networkaddress.cache.ttl" , "60");.

• Plan DTS task handling: If you have active DTS tasks, plan ahead. You must manually restart these tasks after migration.

• Business remains accessible: Data moves during migration, but your RDS SQL Server instance stays accessible. Business operations are unaffected.

• Regular backup limitation: If you choose to switch during the maintenance window, regular backups are disabled from task submission until migration completes.

After migration

• Verify configuration consistency: Instance name, port, tags, database accounts, and other settings remain unchanged. Confirm these configurations work correctly.

• Clear DNS cache: Clear your client’s DNS cache promptly to avoid connection failures caused by stale entries.

• Validate connectivity: Use the endpoint to verify the instance is accessible and confirm business functions operate normally.

• Restart DTS tasks: If you had active DTS tasks before migration, manually restart them to ensure proper operation.