All Products
Search
Document Center

ApsaraDB RDS:Migrate an ApsaraDB RDS for PostgreSQL instance across zones in the same region

Last Updated:Dec 26, 2023

This topic describes how to migrate an ApsaraDB RDS for PostgreSQL instance across zones in the same region. After your RDS instance is migrated, its attributes, configuration, and endpoints remain unchanged. The 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 a few hours.

Prerequisites

  • The region in which your RDS instance resides consists of multiple zones. For more information about the regions and zones of Alibaba Cloud, see Regions and zones.

  • Your RDS instance is a primary RDS instance, and no read-only RDS instances are attached to the RDS instance.

  • Your RDS instance is in the Running state.

Limits

  • If your database system uses local disks, you can migrate only the primary RDS instance across zones in the same region.

  • You cannot migrate a serverless RDS instance to another zone. For more information, see Overview.

Billing rules

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

  • If your RDS instance uses standard SSDs, the storage type of the RDS instance is automatically upgraded from standard SSD to PL1 ESSD during the cross-zone migration. After the upgrade, the billing of storage resources remains unchanged.

Impacts

  • 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 cross-zone 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 cross-zone migration, you must immediately delete the cached DNS records from the database client. If the database client runs 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. 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

    For more information about how to set the TTL in the JVM configuration, see Class InetAddress.

  • If your RDS instance has an ongoing Data Transmission Service (DTS) task, you must restart the DTS task after the migration is complete.

  • ApsaraDB RDS for PostgreSQL instances that use standard SSDs are no longer available for purchase. If the storage type of your RDS instance is standard SSD, the system automatically upgrades the storage type of your RDS instance from standard SSD to PL1 ESSD during the cross-zone migration. For more information, see [EOS/Discontinuation] End of sale for the standard SSD storage type for specific database engines in ApsaraDB RDS from July 01, 2022.

Migration scenarios

Migration type

Scenario

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 select the multi-zone deployment method 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

  1. 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.
  2. In the Basic Information section, click Migrate Data Across Zones.

  3. In the dialog box that appears, specify the zones and vSwitches of the primary and secondary RDS instances and click Yes.

    Parameters

    Parameter

    Description

    Configure Primary Zone

    Select destination zones for the primary and secondary RDS instances.

    • If your database system uses local disks, you can migrate only the primary RDS instance across zones in the same region. You cannot migrate the secondary RDS instance.

    • If the RDS instance uses cloud disks, you can change the zones of the primary and secondary RDS instances at the same time or change the zone only of the primary or secondary RDS instance. Example:

      • The primary RDS instance resides in Singapore Zone A and the secondary RDS instance resides in Singapore Zone B. You can migrate the primary RDS instance to Singapore Zone C and the secondary RDS instance to Singapore Zone D.

      • The primary RDS instance resides in Singapore Zone A and the secondary RDS instance resides in Singapore Zone B. You can retain the primary RDS instance in Singapore Zone A and migrate only the secondary RDS instance to Singapore Zone C.

      Note

      If you separately migrate the primary or secondary RDS instance to another zone, you need to only configure the zone to which you want to migrate the instance.

    Configure Secondary Zone

    vSwitch in Primary Zone

    Select vSwitches in the destination zones for the primary and secondary RDS instances. If no vSwitches are available in the destination zones, create vSwitches. For more information, see Create and manage a vSwitch.

    vSwitch in Secondary Zone

    Switching Time

    • Switch Now: The switchover is immediately performed.

    • Switchover Within Maintenance Window: The switchover is performed during the specified maintenance window. For more information, see Set the maintenance window of an ApsaraDB RDS for PostgreSQL instance.

    • Take Effect at Specified Time Range: The switchover is performed at a specified point in time.

    After you click Yes, 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 the data is replicated, the system switches your workloads based on the time that is specified by the Switching Time parameter. You can set the Switching Time parameter to Switch Now, Switchover Within Maintenance Window, or Take Effect at Specified Time Range.

    Warning

    The migration triggers a transient connection. 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 after the migration.

    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 zones 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.

Related operations

Operation

Description

MigrateToOtherZone

Migrates an instance across zones.