Performing a minor version upgrade

You can use the following methods to upgrade the minor version of a DB cluster or to patch a DB cluster:

Before performing a minor version upgrade

We recommend that you perform the following actions to reduce the downtime during a minor version upgrade:

How to perform minor version upgrades and apply patches

Minor version upgrades and patches become available in Amazon Web Services Regions only after rigorous testing. Before releasing upgrades and patches, Aurora PostgreSQL tests to ensure that known security issues, bugs, and other issues that emerge after the release of the minor community version don't disrupt overall Aurora PostgreSQL fleet stability.

As Aurora PostgreSQL makes new minor versions available, the instances that make up your Aurora PostgreSQL DB cluster can be automatically upgraded during your specified maintenance window. For this to happen, your Aurora PostgreSQL DB cluster must have the Enable auto minor version upgrade option turned on. All DB instances that make up your Aurora PostgreSQL DB cluster must have the automatic minor version upgrade (AmVU) option turned on so that the minor upgrade to be applied throughout the cluster.

You can check the value of the Enable auto minor version upgrade option for all your Aurora PostgreSQL DB clusters by using the describe-db-instances Amazon CLI command with the following query.

aws rds describe-db-instances \
  --query '*[].{DBClusterIdentifier:DBClusterIdentifier,DBInstanceIdentifier:DBInstanceIdentifier,AutoMinorVersionUpgrade:AutoMinorVersionUpgrade}'

This query returns a list of all Aurora DB clusters and their instances with a true or false value for the status of the AutoMinorVersionUpgrade setting. The command as shown assumes that you have your Amazon CLI configured to target your default Amazon Web Services Region.

For more information about the AmVU option and how to modify your Aurora DB cluster to use it, see Automatic minor version upgrades for Aurora DB clusters.

You can upgrade your Aurora PostgreSQL DB clusters to new minor versions either by responding to maintenance tasks, or by modifying the cluster to use the new version.

You can identify any available upgrades or patches for your Aurora PostgreSQL DB clusters by using the RDS console and opening the Recommendations menu. There, you can find a list of various maintenance issues such as Old minor versions. Depending on your production environment, you can choose to Schedule the upgrade or take immediate action, by choosing Apply now, as shown following.

To learn more about how to maintain an Aurora DB cluster, including how to manually apply patches and minor version upgrades, see Maintaining an Amazon Aurora DB cluster.

Minor release upgrades and zero-downtime patching

Upgrading an Aurora PostgreSQL DB cluster involves the possibility of an outage. During the upgrade process, the database is shut down as it's being upgraded. If you start the upgrade while the database is busy, you lose all connections and transactions that the DB cluster is processing. If you wait until the database is idle to perform the upgrade, you might have to wait a long time.

The zero-downtime patching (ZDP) feature improves the upgrading process. With ZDP, both minor version upgrades and patches can be applied with minimal impact to your Aurora PostgreSQL DB cluster. ZDP is used when applying patches or newer minor version upgrades to Aurora PostgreSQL versions and other higher releases of these minor versions and newer major versions. That is, upgrading to new minor versions from any of these releases onward uses ZDP.

The following table shows the Aurora PostgreSQL versions and DB instance classes where ZDP is available:

ZDP works by preserving current client connections to your Aurora PostgreSQL DB cluster throughout the Aurora PostgreSQL upgrade process. However, in the following cases, connections will be dropped for ZDP to complete:

During the upgrade process using ZDP, the database engine looks for a quiet point to pause all new transactions. This action safeguards the database during patches and upgrades. To make sure that your applications run smoothly with paused transactions, we recommend integrating retry logic into your code. This approach ensures that the system can manage any brief downtime without failing and can retry the new transactions after the upgrade.

When ZDP completes successfully, application sessions are maintained except for those with dropped connections, and the database engine restarts while the upgrade is still in progress. Although the database engine restart can cause a temporary drop in throughput, this typically lasts only for a few seconds or at most, approximately one minute.

In some cases, zero-downtime patching (ZDP) might not succeed. For example, parameter changes that are in a pending state on your Aurora PostgreSQL DB cluster or its instances interfere with ZDP.

You can find metrics and events for ZDP operations in Events page in the console. The events include the start of the ZDP upgrade and completion of the upgrade. In this event you can find how long the process took, and the numbers of preserved and dropped connections that occurred during the restart. You can find details in your database error log.

Upgrading the Aurora PostgreSQL engine to a new minor version

You can upgrade your Aurora PostgreSQL DB cluster to a new minor version by using the console, the Amazon CLI, or the RDS API. Before performing the upgrade, we recommend that you follow the same best practice that we recommend for major version upgrades. As with new major versions, new minor versions can also have optimizer improvements, such as fixes, that can cause query plan regressions. To ensure plan stability, we recommend that you use the Query Plan Management (QPM) extension as detailed in Ensuring plan stability after a major version upgrade.

aws rds modify-db-cluster \
    --db-cluster-identifier mydbcluster \
    --engine-version new_version \
    --no-apply-immediately

aws rds modify-db-cluster ^
    --db-cluster-identifier mydbcluster ^
    --engine-version new_version ^
    --no-apply-immediately