This topic describes how to migrate an ApsaraDB RDS for MySQL instance across zones in the same region. The amount of time that is required to complete the migration varies based on the amount of data that needs to be migrated. In most cases, the migration requires a few hours.
- Your RDS instance runs RDS High-availability Edition or RDS Basic Edition.
- Your RDS instance is in the Running state.
- If your RDS instance uses standard SSDs or enhanced SSDs (ESSDs), the minor engine version of your RDS instance is 20201031 or later. For more information about how to update the minor engine version, see Update the minor engine version of an ApsaraDB RDS for MySQL instance.
- The region to which your RDS instance belongs consists of multiple zones. For more information, see Regions and zones.
- The network connection mode of your RDS instance is upgraded. For more information, see [Important] RDS network link upgrade.
- Your RDS instance does not use a phased-out instance type. For more information about how to change the instance type, see Change the specifications of an ApsaraDB RDS for MySQL instance.
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:
You are not charged for the migration. This applies even if you migrate your RDS instance from one zone to multiple zones.
- 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 database system.
- The migration causes changes to the virtual IP addresses of your RDS instance. We recommend that you use an endpoint rather than an IP address of your RDS instance 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 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 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 local applications. This must be completed before you call the
InetAddress.getByName()function for the first time or before you establish a network connection.
- If your RDS instance is associated with an DRDS instance, the changes of the virtual IP addresses temporarily interrupt the connection between your RDS instance and the DRDS instance. You must manually configure the connection at the earliest opportunity. For more information, see Fix database shard connections.
- If your RDS instance has an ongoing Data Transmission Service (DTS) task, you must restart the DTS task after the migration is complete.
|Migration from one zone to another zone||The original zone where your RDS instance resides cannot ensure service 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 when the single-zone deployment method is used.|
- Access RDS Instances, select a region at the top, and then click the ID of the target RDS instance.
- In the Basic Information section of the page that appears, click Migrate Across Zones.
- In the dialog box that appears, specify the destination primary zone, the vSwitch
in the destination primary zone, and the switching time. Then, click OK. Note
- After you click OK, ApsaraDB RDS starts to copy the data of the RDS instance to the destination primary zone. You can set the switching time to Migrate Immediately or Switch Within Maintenance Window. The switchover triggers a transient connection. 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 after the workloads are switched over to the destination primary zone.
- 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 transient connection. If the database client runs on a JVM, we recommend that you set the 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 the 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. For more information, see the "Impacts" section of this topic.
|Migrate an instance across multiple zones||Migrates an ApsaraDB RDS instance across zones in the same region.|