This topic describes how to upgrade the major version of an ApsaraDB RDS for PostgreSQL instance. For example, you can upgrade the major version from PostgreSQL 10.0 to PostgreSQL 11.0. During the upgrade process, ApsaraDB RDS creates a new RDS instance and copies the data of the original RDS instance to the new RDS instance.

The PostgreSQL community releases a major version every year and provides five years of support for each version. Compared with the previous release, each new version includes revolutionary improvements in both functionality and performance. The PostgreSQL community does not provide support for versions that have been released for more than five years. As a result, the performance and security risks of these versions may increase.

ApsaraDB RDS for PostgreSQL provides the major version upgrade feature. You can use this feature to upgrade the major version of your RDS instance. This increases the performance and functionality of your database service. This also mitigates the security risks of your database service. To upgrade the major version of your RDS instance, you must perform the following steps:

  1. Create an upgrade check report.

    Check whether the original RDS instance supports major version upgrades. Then, view the check result and the check report.

  2. Perform a major version upgrade.

    Specify the destination major version. You can select the No cutting configuration method. This configuration method allows you to test whether the destination major version is compatible with your workloads. After the destination major version passes the compatibility test, you can select the Cutover configuration method and perform an official upgrade.

Prerequisites

  • The original RDS instance runs PostgreSQL 10.0, 11.0, or 12.0.
  • The original RDS instance runs the High-availability Edition. For more information, see High-availability Edition.
  • The original RDS instance uses standard or enhanced SSDs.
  • The original RDS instance resides in a virtual private cloud (VPC). If the original RDS instance resides in the classic network, you must switch the original RDS instance to a VPC. This must be finished before you perform an upgrade. For more information about how to view or change the network type of an RDS instance, see Change the network type of an ApsaraDB RDS for PostgreSQL instance.
  • The original RDS instance is a primary instance. It cannot be a read-only instance. In addition, it cannot be created in a dedicated cluster. For more information, see Overview of read-only ApsaraDB RDS for PostgreSQL instances and What is ApsaraDB for MyBase?
  • The ID of the original RDS instance does not start with pg-cn.

Highlights

  • Cross-version upgrade: You can upgrade the original RDS instance between major versions. For example, you can upgrade the instance from PostgreSQL 10.0 to PostgreSQL 13.0.
  • Upgrade trial: You can select the No cutting configuration method. This configuration method allows you to verify the upgrade process without interruptions to the workloads on the original RDS instance.
  • Smooth upgrade:
    • No application modification: The Cutover configuration method is used to perform an official upgrade. In this case, the new RDS instance is connected by using the same endpoint as the original RDS instance. You do not need to modify the endpoint configuration on your application.
    • No downtime: The upgrade process does not require downtime on the original RDS instance. This mitigates the risk of service interruption. However, the original RDS instance processes only read requests during the upgrade process. In addition, an upgrade is implemented by using instance cloning. The original RDS instance is not affected even if the upgrade fails.
    • Instance configuration carry-over:
      • The new RDS instance carries over the IP address whitelists, parameter settings, and plug-ins of the original RDS instance. This does not apply to the plug-ins or parameters that are not supported by the destination major version.
      • If the original RDS instance is fully encrypted, the new RDS instance is also fully encrypted. In addition, the key that is used to encrypt data is retained. For more information, see Create a fully encrypted database on an ApsaraDB RDS for PostgreSQL instance.

Billing

The new RDS instance is billed on a pay-as-you-go basis. After you check that your workloads run as normal on the new RDS instance, you can switch the new RDS instance to the subscription billing method. Then, you can release the original RDS instance. For more information, see Switch from pay-as-you-go billing to subscription billing and Release or unsubscribe from an ApsaraDB RDS for PostgreSQL instance.

Impacts

  • When an upgrade is in progress, the original RDS instance processes only read requests. In addition, you experience a transient connection error of a few minutes. Therefore, we recommend that you perform an upgrade during off-peak hours.
    Note The duration of the transient connection error varies based on the data size and the DNS cache refresh interval.

    You can switch to another vSwitch. Then, you can evaluate the DNS cache refresh interval of your database client based on the duration of the transient connection error. For more information, see Switch to a new vSwitch for an RDS PostgreSQL instance.

  • If some parameters of the original RDS instance are not supported by the destination major version, ApsaraDB RDS does not include these parameters at the creation of the new RDS instance.
  • The new RDS instance does not carry over the alert rules of the original RDS instance. These alert rules are configured by using Cloud Monitor. For more information, see Configure an alert rule on an ApsaraDB RDS for PostgreSQL instance.

Procedure

  1. Go to the Upgrade Major Version page.
    1. Log on to the ApsaraDB for RDS console. In the left-side navigation pane, click Instances. In the top navigation bar, select the region where your RDS instance resides.
      选择地域
    2. Find your RDS instance and click its ID. In the left-side navigation pane of the page that appears, click Upgrade Major Version.
      Note
      • You can find the Upgrade Major Version menu item only when your RDS instance meets all the requirements that are described in the "Prerequisites" section of this topic.
      • The major version upgrade feature is available only in the new ApsaraDB RDS console.
  2. On the Upgrade Check tab, select the destination major version and click create upgrade check report. This may require a few minutes.
    Note
    • If the destination major version fails the upgrade check and the "Checking for presence of required libraries" check item shows the fatal state, you need to execute the SELECT * FROM pg_extension; statement on your RDS instance. This allows you to check the plug-ins that are used. Then, you need to identify and uninstall the plug-ins that are not supported by the destination major version. For more information, see Plug-ins supported.
    • If you execute the CREATE EXTENSION statement on your RDS instance after the destination major version passes the upgrade check, you must perform the upgrade check again.
  3. Click the Upgrade Instance tab, read the displayed warning, select the destination major version, and then click continue to create upgrade instance.
  4. In the message that appears, read the tips and click OK.
    Parameter Description
    Storage type Select the type of storage media that the new RDS instance uses.

    The major version upgrade feature is dependent on SSD snapshots. You must select the type of storage media that the original RDS instance uses. For example, if the original RDS instance uses standard SSDs, you must select the standard SSD storage type for the new RDS instance.

    Cutover configuration Specify whether ApsaraDB RDS automatically switches your workloads over to the new RDS instance after the data migration is complete.
    • No cutting: ApsaraDB RDS does not automatically switch your workloads over to the new RDS instance. This configuration method is used to test whether the destination major version is compatible with your workloads. Before you perform an official upgrade, we recommend that you select the No cutting configuration method and perform a compatibility test. After the destination major version passes the compatibility test, you can release the original RDS instance. Then, you can select the Cutover configuration method and perform an official upgrade. For more information, see Release or unsubscribe from an ApsaraDB RDS for PostgreSQL instance and the "Procedure" section of this topic.
      Note
      • The data migration process does not interrupt your workloads on the original RDS instance.
      • If you select the No cutting configuration method, you must update the endpoint configuration on your application after the data migration is complete. This update requires that you replace the endpoint of the original RDS instance with the endpoint of the new RDS instance. For more information about how to view the endpoint of an RDS instance, see View and change the internal and public endpoints and port numbers of an ApsaraDB RDS for PostgreSQL instance.
    • Cutover: ApsaraDB RDS automatically switches your workloads over to the new RDS instance. After the switchover is complete, you do not need to update the endpoint configuration on your application. Your application can automatically connect to the new RDS instance. This configuration method is used to perform an official upgrade. After you confirm that the destination major version is compatible with your workloads, we recommend that you select this configuration method.
      Note
      • After the switchover is complete, you cannot roll your workloads back to the original RDS instance. Proceed with caution.
      • When the switchover is in progress, the original RDS instance processes only read requests. Make sure that you perform the switchover during off-peak hours.
      • If the original RDS instance is attached with read-only RDS instances, you cannot select the Cutover configuration method. In this case, you can upgrade the original RDS instance only by using the No cutting configuration method. In addition, the read-only RDS instances that are attached to the original RDS instances cannot be cloned. After the upgrade is complete, you must create read-only RDS instances that run the destination major version for the original RDS instance. For more information, see Create a read-only ApsaraDB RDS for PostgreSQL instance.
    Cutover time Specify the time when ApsaraDB RDS switches your workloads over to the new RDS instance after the data migration is complete.
    • immediately: After the data migration is complete, ApsaraDB RDS immediately switches your workloads over to the new RDS instance.
    • Instance operation and maintenance time: ApsaraDB RDS switches your workloads over to the new RDS instance during the specified maintenance window. For more information, see Set the maintenance window of an ApsaraDB RDS for PostgreSQL instance.
    Note This parameter appears only when you set the Cutover configuration parameter to Cutover.
    Statistical information collection mode Specify the time when you want to collect the statistics of the new RDS instance.
    • Collection before cutting: This option ensures the stability of your database service. However, if the size of data on the original RDS instance is large, the upgrade process may require a long period of time.
    • Collection after cutting: This option accelerates the upgrade process. However, if you access tables for which no statistics are generated, the specified query plans may be inaccurately executed. In addition, your database service may become unavailable during peak hours.
    Note If you select the No cutting configuration method, the Collection before cutting option indicates that you can collect the statistics of the new RDS instance before the instance starts to process read and write requests. In addition, the Collection after cutting option indicates that you can collect the statistics of the new RDS instance after the instance starts to process read and write requests.
    Storage space Specify the storage capacity of the new RDS instance.
    Instance specification Specify the specifications of the new RDS instance. For more information about instance types, see Primary instance types.
  5. Click Create now.
    The status of the original RDS instance changes to EngineVersionUpgrading. In addition, you can find a new RDS instance on the Instances page. The new RDS instance is in the Creating state. When the status of both the original and new RDS instances changes to Running, the new RDS instance is created and the upgrade is complete. The length of time that is required varies based on the data size. Wait before the upgrade is complete.
    Note After an upgrade task is created, you cannot modify or delete the task. To delete a created upgrade task, you must submit a ticket.

What to do next

  1. After you confirm that your workloads run as normal on the new RDS instance, switch the new RDS instance to the subscription billing method. For more information, see Switch from pay-as-you-go billing to subscription billing.
  2. Release the original RDS instance. For more information, see Release or unsubscribe from an ApsaraDB RDS for PostgreSQL instance.
  3. Create read-only RDS instances that are used to offload read requests from the new RDS instance. The new RDS instance does not carry over the read-only RDS instances of the original RDS instance. For more information, see Create a read-only ApsaraDB RDS for PostgreSQL instance.