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 to PostgreSQL 11.
The PostgreSQL community releases a new major engine version every year and provides five years of technical support for each version. Each new version includes improvements in terms of functionality and performance compared with previous versions. The PostgreSQL community does not provide technical support for versions that were released five years ago or earlier, which increases the probability of performance risks and security risks of these versions.
ApsaraDB RDS for PostgreSQL provides a major engine version upgrade feature. This feature increases 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, you must perform the following steps:
- 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 check result in the upgrade check report is Fail, you cannot upgrade the major engine version.
- Upgrade the major engine version.
- Select the No cutting configuration method. ApsaraDB RDS creates an RDS instance that runs the new major engine version 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. ApsaraDB RDS creates an RDS instance that runs the new major version. After the data of the original RDS instance is migrated to the new RDS instance, ApsaraDB RDS switches your workloads over to the new RDS instance.
Usage notes
- The original RDS instance must meet the following requirements:
- The original instance must run PostgreSQL 13, PostgreSQL 12, PostgreSQL 11, PostgreSQL 10, or PostgreSQL 9.4.
- The original RDS instance runs RDS High-availability Edition or RDS Basic Edition. For more information, see High-availability Edition and RDS Basic Edition.
- The original RDS instance resides in a virtual private cloud (VPC).
If the original RDS instance resides in the classic network, you must change the network type of the original RDS instance to VPC before you perform an upgrade. When you change the network type, clear Reserve original classic network endpoint. 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.
Note If you select Reserve original classic network endpoint, you must wait until the retention period of the endpoint ends before you can perform the upgrade task. - 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
. - The RDS instance does not use a new general-purpose instance type. For more information,
see Primary ApsaraDB RDS for PostgreSQL instance types.
Note The new general-purpose instance types provide better scalability and performance and reduce the time to create an RDS instance or change the specifications of an RDS instance. However, the new general-purpose instance types do not support the upgrade of major engine versions.
- An upgrade has the following impacts:
- If you select the Cutover configuration method, ApsaraDB RDS needs to switch your
workloads over to a new RDS instance during the upgrade process. The original RDS
instance processes only read requests and a transient connection that lasts a few
minutes occurs during the switchover. 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 the amount of data and the intervals at which the DNS cache is refreshed. You can switch to a different vSwitch. Then, you can estimate the intervals to refresh caches 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 to complete an upgrade varies based on the amount of data on the original RDS instance. The time that is required for a switchover varies only based on the number of objects that are defined in the original RDS instance. These objects include the defined tables, defined indexes, defined views, user-defined functions (UDFs), and defined sequences. For example, the time that is required for a switchover when 100 tables with 1 GB of data in total are defined is the same as the time that is required for a switchover when 100 tables with 10 TB of data in total are defined.
- If the original RDS instance uses a parameter that is not supported by the new major engine version, the parameter is deleted from the new RDS instance. 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, and 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 serves as the source RDS instance or destination RDS instance of a migration task that is created in the Data Transmission Service (DTS) console, you must re-create the migration task after you perform an upgrade. For more information about how to create a DTS task, see DTS documentation.
- After an upgrade is complete, the read-only RDS instances and logical replication slots that you created in 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 you select the Cutover configuration method, ApsaraDB RDS needs to switch your
workloads over to a new RDS instance during the upgrade process. The original RDS
instance processes only read requests and a transient connection that lasts a few
minutes occurs during the switchover. 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.
- 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:
- Change the endpoint of the read-only RDS instance to the endpoint of the original
RDS instance on your application.
Note For service stability purposes, we recommend that you modify the endpoint configuration on your application during off-peak hours.
- Delete the read-only RDS instance.
- Upgrade the major engine version. For more information, see Procedure.
- 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.
- Change the endpoint of the original RDS instance to the endpoint of the new read-only RDS instance on your application.
- Change the endpoint of the read-only RDS instance to the endpoint of the original
RDS instance on your application.
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 to PostgreSQL 13.
- 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: An upgrade 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 for a few minutes during the upgrade process. In addition, ApsaraDB RDS performs the upgrade by using RDS instance cloning. The original RDS instance is not affected even if the upgrade fails.
- Reserved instance configuration:
- The new RDS instance carries over the IP address allowlists, 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.
Pricing
You are charged for the new RDS instance based on the pay-as-you-go billing method. After you verify that your workloads run as expected on the new RDS instance, you can change 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
What to do next
- After you verify that your workloads run as expected on the new RDS instance, change 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.
- Release the original RDS instance. For more information, see Release or unsubscribe from an ApsaraDB RDS for PostgreSQL instance.
- Create read-only RDS instances for the new RDS instance based on your business requirements because 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.
Related operations
Operation | Description |
---|---|
UpgradeDBInstanceMajorVersionPrecheck | Checks the compatibility between a new major engine version and workloads on an ApsaraDB RDS for PostgreSQL instance before an upgrade |
DescribeUpgradeMajorVersionPrecheckTask | Queries the check report for a major engine version upgrade to an ApsaraDB RDS for PostgreSQL instance |
UpgradeDBInstanceMajorVersion | Upgrades the major engine version of an ApsaraDB RDS for PostgreSQL instance |
DescribeUpgradeMajorVersionTask | Queries the tasks that are created to upgrade the major engine version of an ApsaraDB RDS for PostgreSQL instance |