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

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

ApsaraDB RDS for PostgreSQL has a major engine version upgrade feature. This feature can increase the performance and functionality of your database service and mitigate the risks that an upgrade may cause. To upgrade the major engine version of the original RDS instance by using this feature, perform the following steps:

  1. Perform an upgrade check.

    Check whether the original RDS instance supports major engine version upgrades. Then, view the check report that is generated. If the result of a check item in the check report is abnormal, you cannot upgrade the major engine version.

  2. Upgrade the major engine version.

    Select the No cutting configuration method and create an RDS instance for testing. This RDS instance is used to test whether the new major engine version is compatible with your workloads. After the new major engine version passes the compatibility test, select the Cutover configuration method and perform an upgrade.

Precautions

  • The original RDS instance must meet the following requirements:
    • The original RDS instance runs PostgreSQL 12.0, PostgreSQL 11.0, PostgreSQL 10.0, or PostgreSQL 9.4.
    • The original RDS instance runs the RDS High-availability Edition. For more information, see High-availability Edition.
    • The original RDS instance resides in a virtual private cloud (VPC). If the original RDS instance resides in the classic network, you must migrate the original RDS instance to a VPC 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. The original RDS instance cannot be a read-only instance and 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.
  • An upgrade has the following impacts:
    • If you select the Cutover configuration method, the original RDS instance processes only read requests during the upgrade process. In addition, a transient connection that lasts a few minutes occurs. Therefore, we recommend that you perform an upgrade during off-peak hours. If you select the No cutting configuration method, the original RDS instance is not affected.
      Note
      • The duration of the transient connection varies based on both the amount of data and the intervals at which the DNS cache is refreshed. You can switch to another vSwitch. Then, you can estimate the cache refresh interval of your database client based on the duration of the transient connection. For more information, see Switch an ApsaraDB RDS for PostgreSQL instance to a different vSwitch.
      • The time that is required for an upgrade varies based on the amount of data. The time that is required to switch your workloads over to the new RDS instance does not vary based on the amount of data. The time varies based on the number of objects that are defined. These objects include the defined tables, defined indexes, defined views, user-defined functions, and defined sequences. For example, the time required when 100 tables with 1 GB of data in total are defined is the same as the time required when 100 tables with 10 TB of data in total are defined.
    • If the original RDS instance uses a parameter that is not supported in the new major engine version, ApsaraDB RDS deletes the parameter from the new major engine version. If the value of a parameter in the previous major engine version is not within the value range that is supported in the new major engine version, ApsaraDB RDS sets the parameter to the default value that is specified in the new major engine version.
    • The new RDS instance does not carry over the name, tags, alert rules, or backup data of the original RDS instance. For more information, see Add tags to ApsaraDB RDS for PostgreSQL instances, Configure an alert rule on an ApsaraDB RDS for PostgreSQL instance, and Back up an ApsaraDB RDS for PostgreSQL instance.
    • If the original RDS instance is the source RDS instance or new RDS instance of a migration task that is created in the Data Transmission Service (DTS) console, you must create the migration task again after you perform an upgrade. For more information about how to create a migration task in DTS, see What is DTS?
    • After an upgrade is complete, the read-only RDS instances and logical replication slots that you created on the original RDS instance remain attached to the original RDS instance rather than the new RDS instance. You must create read-only RDS instances and logical replication slots on the new RDS instance after the upgrade.
  • If a read-only RDS instance is attached to the original RDS instance, you must perform the following operations before and after you perform an upgrade:
    1. On your application, change the endpoint of the read-only RDS instance to the endpoint of the original RDS instance.
      Note For service stability purposes, we recommend that you modify the endpoint configuration on your application during off-peak hours.
    2. Delete the read-only RDS instance.
    3. Perform an upgrade. For more information, see the "Procedure" section of this topic.
    4. After the upgrade is complete, create a read-only RDS instance on the new RDS instance. For more information, see Create a read-only ApsaraDB RDS for PostgreSQL instance.
    5. On your application, change the endpoint of the original RDS instance to the endpoint of the new read-only RDS instance.

Highlights

  • Cross-version upgrade: You can upgrade the major engine version of the original RDS instance to a later version. For example, you can upgrade the major engine version from PostgreSQL 10.0 to PostgreSQL 13.0.
  • Upgrade trial: You can use the No cutting configuration method to verify the feasibility of an upgrade without interruptions to your workloads on the original RDS instance.
  • Smooth upgrade:
    • No application modification: You can use the Cutover configuration method to perform an 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 cause downtime on the original RDS instance. This mitigates the risks of service interruption. However, the original RDS instance processes only read requests during the upgrade process. In addition, an upgrade is implemented by using RDS instance cloning. In this case, the original RDS instance is not affected even if the upgrade fails.
    • Reserved instance configuration:
      • The new RDS instance carries over the IP address whitelists, parameter settings, and plug-ins of the original RDS instance. However, this does not apply to the plug-ins or parameters that are not supported in the new major engine version.
      • If the original RDS instance supports fully encrypted databases, the new RDS instance also supports fully encrypted databases and carries over the key that is used on the original RDS instance to encrypt data. 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 verify that your workloads run as expected on the new RDS instance, you can switch the billing method of the new RDS instance to subscription. Then, you can release the original RDS instance. For more information, see Switch an ApsaraDB RDS for PostgreSQL instance from pay-as-you-go to subscription and Release or unsubscribe from an ApsaraDB RDS for PostgreSQL instance.

Procedure

  1. If a read-only RDS instance is attached to the original RDS instance, perform the following steps before you perform an upgrade:
    1. On your application, change the endpoint of the read-only RDS instance to the endpoint of the original RDS instance.
      Note For service stability purposes, we recommend that you modify the endpoint configuration on your application during off-peak hours.
    2. Delete the read-only RDS instance.
  2. Go to the Upgrade Major Version page.
    1. In the left-side navigation pane, click Upgrade Major Version.
      Upgrade Major Version
      Note
      • If the Major Version Upgrade menu item cannot be found, you must check that your RDS instance meets all the requirements that are described in the "Precautions" section of this topic.
      • The major engine version upgrade feature is available only in the new ApsaraDB RDS console.
  3. On the Upgrade Check tab, select the new major engine version and click Create upgrade check report. This process may require a few minutes.
    Note
    • Before you perform an upgrade, you must make sure that your RDS instance passes the upgrade check. This helps ensure that the upgrade is successful.
    • If you execute a CREATE EXTENSION statement on your RDS instance after the new major engine version passes the upgrade check, you must perform an upgrade check again.

    If the upgrade check report indicates that your RDS instance fails the upgrade check, you can click See information in the Report content column to view the details about the report. For more information, see Introduction to the upgrade check report of a major engine version upgrade on an ApsaraDB RDS for PostgreSQL instance.

  4. Click the Upgrade Instance tab, read the warning that is displayed, select the new major engine version, and then click Continue to create upgrade instance.
  5. In the message that appears, read the tips and click OK.
    Parameter Description
    Storage type Select the type of storage media that is used for the new RDS instance.
    The major engine version upgrade feature uses SSD snapshots to perform an upgrade. You can select the storage type based on the following conditions:
    • If the original RDS instance uses standard SSDs, you can select the Standard SSD storage type.
    • If the original RDS instance uses enhanced SSDs (ESSDs), you can select the Enhanced SSD, ESSD PL2, or ESSD PL3 storage type.
    • If the original RDS instance uses local SSDs, you can select the Enhanced SSD, ESSD PL2, or ESSD PL3 storage type.
    The Available Zone Specify the zones and vSwitches of the new RDS instance and its secondary RDS instance. You can specify zones that are different from the zones of the original RDS instance.
    For Available Zone
    Primary Instance Switch
    Standby Instance Switch
    Cutover configuration Specify whether ApsaraDB RDS automatically switches your workloads over to the new RDS instance after the data is migrated.
    • 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 new major engine version is compatible with your workloads. Before you perform an upgrade, we recommend that you select the No cutting configuration method and perform a compatibility test. If the new major engine version passes the compatibility test, you can release the new RDS instance. Then, you can select the Cutover configuration method and perform an upgrade. For more information, see Release or unsubscribe from an ApsaraDB RDS for PostgreSQL instance and the "Procedure" section of this topic.
      Note
    • 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 automatically connects to the new RDS instance. This configuration method is used to perform an upgrade after you verify that the new major engine version is compatible with your workloads.
      Note
      • After the switchover is complete, you cannot roll your workloads back to the original RDS instance. Proceed with caution.
      • During the switchover, the original RDS instance processes only read requests. You must make sure that you perform the switchover during off-peak hours.
      • If read-only RDS instances are attached to the original RDS instance, 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 instance cannot be cloned. After the upgrade is complete, you must create read-only RDS instances that run the new major engine version for the new 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 is migrated.
    • Immediately: After the data is migrated, 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 maintenance window that you specify. For more information, see Set the maintenance window of an ApsaraDB RDS for PostgreSQL instance.
    Note This parameter is available 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. If the original RDS instance contains a large amount of data, the upgrade process may require a long period of time.
    • Collection after cutting: This option accelerates the upgrade process. If you access tables for which no statistics are generated, the query plans that you specify 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 new RDS instance starts to process read and write requests. The Collection after cutting option indicates that you can collect the statistics of the new RDS instance after the new RDS instance starts to process read and write requests.
    Storage space Specify the storage capacity of the new RDS instance.
    Instance specification Specify the instance type of the new RDS instance. For more information about the instance types that are supported, see Primary instance types.
  6. 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 statuses of the original RDS instance and new RDS instance change to Running, the new RDS instance is created and the upgrade is complete. The time that is required for the upgrade varies based on the amount of data. You may need to wait a few minutes for the upgrade to finish.
    Note After an upgrade task is created, you cannot modify or delete the task. If you want to delete an upgrade task, you must submit a ticket.
  7. Perform the following steps after the upgrade. This step is required only when a read-only RDS instance is attached to the original RDS instance and you deleted the read-only RDS instance in Step 1.
    1. Create a read-only RDS instance for the new RDS instance. For more information, see Create a read-only ApsaraDB RDS for PostgreSQL instance.
    2. On your application, change the endpoint of the original RDS instance to the endpoint of the new read-only RDS instance. For more information, see Step 1.

What to do next

  1. After you verify that your workloads run as expected on the new RDS instance, switch the billing method of the new RDS instance to subscription. For more information, see Switch an ApsaraDB RDS for PostgreSQL instance from pay-as-you-go to subscription.
  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.