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

Prerequisites

  • The storage type, PostgreSQL version, RDS edition, and instance family of your RDS instance meet the requirements for cross-zone migration. For more information, see the following table.
    Storage type PostgreSQL version RDS edition Instance family Description
    Standard SSD or ESSD PostgreSQL 14, PostgreSQL 13, PostgreSQL 12, PostgreSQL 11, or PostgreSQL 10 High-availability Edition Dedicated instance family The migration is supported for all RDS instances that use one of the dedicated instance types.
    General-purpose instance family The migration is supported only for RDS instances that use one of the following instance types:
    • pg.n2.medium.2c
    • pg.n2.small.2c
    Basic Edition General-purpose instance family The migration is not supported.
    Local SSD RDS PostgreSQL 10 High-availability Edition General-purpose instance family The migration is supported for RDS instances that use local SSDs.
    RDS PostgreSQL 9.4 High-availability Edition Dedicated instance family
    General-purpose instance family
  • The region to which your RDS instance belongs 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 your RDS instance.

Precautions

  • If your database system uses standard SSDs or enhanced SSDs (ESSDs), you cannot retain the primary RDS instance in the original zone and migrate only the secondary RDS instance across zones within the same region. Examples:
    • The primary RDS instance resides in Zone A of the Singapore (Singapore) region and the secondary RDS instance resides in Zone B of the Singapore (Singapore) region. You cannot retain the primary RDS instance in Zone A of the Singapore (Singapore) region and migrate only the secondary RDS instance to Zone C of the Singapore (Singapore) region.
    • The primary RDS instance resides in Zone A of the Singapore (Singapore) region and the secondary RDS instance resides in Zone B of the Singapore (Singapore) region. You can migrate the primary RDS instance to Zone C of the Singapore (Singapore) region and the secondary RDS instance to Zone A of the Singapore (Singapore) region.
  • If your database system uses local SSDs, you can migrate only the primary RDS instance across zones in the same region.

Fees

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

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 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 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 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.
  • If your RDS instance has an ongoing Data Transmission Service (DTS) task, you must restart the DTS 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 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 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 page that appears, click Migrate Across Zones.
  3. In the dialog box that appears, select the primary zone, secondary zone, and vSwitches, and click OK.
    Migrate an instance across zones

    Parameters

    Parameter Description
    To Primary Zone Select a new Primary Zone and a new Secondary Zone.
    • If your database system uses local SSDs, you can migrate only the primary RDS instance across zones in the same region. You cannot migrate the secondary RDS instance.
    • If your database system uses standard SSDs or ESSDs, you cannot retain the primary RDS instance in the original zone and migrate only the secondary RDS instance across zones within the same region.
      Note For example, the primary RDS instance resides in Zone A of the Singapore (Singapore) region and the secondary RDS instance resides in Zone B of the Singapore (Singapore) region. In this case, if you want to retain the primary RDS instance in Zone A of the Singapore (Singapore) region and migrate the secondary RDS instance to Zone C of the Singapore (Singapore) region, you can perform the following operations:
      1. Migrate the primary RDS instance to Zone C of the Singapore (Singapore) region and the secondary RDS instance to Zone A of the Singapore (Singapore) region.
      2. Perform a primary/secondary switchover. After the switchover is complete, the original secondary RDS instance that resides in Zone A of the Singapore (Singapore) region becomes the new primary RDS instance, and the original primary RDS instance that resides in Zone C of the Singapore (Singapore) region becomes the new secondary RDS instance. For more information, see Switch workloads over between primary and secondary ApsaraDB RDS for PostgreSQL instances.
    To Secondary Zone
    vSwitch in Primary Zone Select vSwitches for the primary zone and the secondary zone. If no vSwitches are available in the destination zones, create vSwitch in the destination zones. For more information, see Create a vSwitch.
    vSwitch in Secondary Zone
    Switching Time
    • Migrate Immediately: The migration is immediately started after you configure the migration.
    • Switch within the set time period: Click Change to select a time period during which you want to perform the migration.

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

    Note
    • 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, your RDS instance encounters another transient connection. 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. For more information, see the "Impacts" section of this topic.

Related operations

Operation Description
Migrate an instance across multiple zones Migrates an ApsaraDB RDS instance across zones in the same region.