This topic describes how to migrate an ApsaraDB RDS for MySQL instance across zones in the same region. After the migration is complete, the attributes, configuration, and endpoints of your RDS instance remain unchanged. The time that is required to complete the migration varies based on the amount of the data that is to be migrated. In most cases, the migration requires a few hours.

Prerequisites

  • Your RDS instance runs one of the following MySQL versions and RDS editions:
    • MySQL 8.0 on RDS High-availability Edition (with local SSDs)
    • MySQL 5.7 on RDS High-availability Edition (with local SSDs)
    • MySQL 5.6 on RDS High-availability Edition (with local SSDs)
    • MySQL 5.5
  • The region where your RDS instance resides provides multiple zones. For more information about regions and zones, see Regions and zones.
  • The network connection mode of your RDS instance is upgraded. For more information, see [Important] RDS network link upgrade.

For more information about how to migrate an RDS instance that runs another database engine, see the following topics:

Fees

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

Precautions

  • During the migration, your database service may be unavailable for a short period of time. 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 rather than an IP address to connect your application to your RDS instance.
  • After the migration, you must immediately delete the cached DNS records from the database client. If the database client on which your application runs is deployed on a Java Virtual Machine (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 VIP that is bound to the in-use endpoint of your RDS instance changes, your application can re-query the related DNS records to obtain the new VIP. Then, your application can connect to the new VIP.
    Note The following TTL-setting methods are provided for reference:
    • Set the TTL for all JVM-based applications: Set the networkaddress.cache.ttl parameter in the $JAVA_HOME/jre/lib/security/java.security file to 60.
    • Set the TTL only for local applications: Specify the networkaddress.cache.ttl java.security.Security.setProperty("networkaddress.cache.ttl" , "60"); setting in the initialized code of the local applications. This must be completed before you call the InetAddress.getByName() function for the first time or before you establish a network connection.
  • The VIP changes temporarily interrupt the availability of DRDS . After the migration is complete, you must immediately update and view the endpoint configuration in the DRDS console.
  • If your RDS instance has an ongoing Data Transmission Service (DTS) task, you must restart the task after the migration is complete.

Migration scenarios

Migration scenario Description
Migration from one zone to another zone The original zone where your RDS instance resides cannot be used to provide the same level of performance due to issues such as heavy loads.
Migration from one zone to multiple zones You want to implement disaster recovery across data centers. After the migration is complete, your RDS instance and its secondary RDS instance reside in different zones.

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.

Migration from multiple zones to one zone You want to use specific features that are supported only for the single-zone deployment method.

Procedure

  1. Visit the RDS instance list, select a region above, and click the target instance ID.
  2. In the Basic Information section of the Basic Information page, click Migrate Across Zones.
  3. In the Migrate Instance Across Zones dialog box, specify the destination primary zone, the vSwitch in the destination primary zone, and the switching time. Then, click OK.

    After you click OK, ApsaraDB RDS starts to copy the data of your RDS instance to the destination primary zone. This does not interrupt the workloads on your RDS instance. After all the data is copied to the destination primary zone, ApsaraDB RDS switches your workloads over to the destination primary zone at the specified switching time. You can set the switching time to Migrate Immediately or Switch Within Maintenance Window.

    Note
    • The switchover triggers a transient connection error. Make sure that your application is configured to automatically reconnect to your RDS instance. Otherwise, you must manually reconnect your application to your RDS instance.
    • If the DNS records cached on the database client are not immediately updated after the migration is complete, some of your workloads may be switched over to the destination primary zone after 10 minutes. This triggers another transient connection error. If the database client on which your application runs is deployed on a JVM, we recommend that you set the TTL in the JVM configuration to 60 seconds or less. In this case, if the VIP that is bound to the in-use endpoint of your RDS instance changes, your application can re-query the related DNS records to obtain the new VIP. Then, your application can connect to the new VIP. For more information, see the "Precautions" section of this topic.
    Migrate Instance Across Zones dialog box

Related operations

Operation Description
Migration zone Migrates an ApsaraDB RDS instance across zones in the same region.