Upgrading the Major Version of a DB Instance Using SQL Commands

Scenarios

You can upgrade the RDS for PostgreSQL major version to enjoy more functions and higher performance and security. Major version upgrades may introduce changes that are backward incompatible with existing versions and affect service running. Therefore, you need to test services on the target version before the upgrade.

In this section, the source instance indicates the DB instance that runs the source version, and the target instance indicates the DB instance that runs the target version.

RDS for PostgreSQL Version Description

• RDS for PostgreSQL v10 and later versions consist of a major version and a minor version. A major version upgrade refers to the upgrade of the major version, such as from 11.x to 12.x.
• Versions earlier than RDS for PostgreSQL v10 consist of two major versions and a minor version. A major version upgrade refers to the upgrade of the major versions, such as from 9.5.x to 9.6.x or from 9.x.x to 10.x.

Preparations

1. View information about the RDS for PostgreSQL DB instance to be upgraded.
   1. On the Instances page, click the DB instance to be upgraded.
   2. On the Basic Information page, view the region, AZ, VPC, subnet, and security group of the DB instance.
2. Prepare an ECS.

   To connect to a DB instance through an ECS, you must first create an ECS.

   The region, AZ, VPC, subnet, and security group of the ECS are the same as those of the RDS for PostgreSQL DB instance to be upgraded.

3. Install a PostgreSQL client on the ECS created in 2.

   For details, see How Can I Install the PostgreSQL Client?

   

   The version of the RDS for PostgreSQL client must be the same as that of the RDS for PostgreSQL instance. The RDS for PostgreSQL instance or client provides pg_dump, pg_restore, and psql.

4. Connect to the source instance through psql and run the following SQL statement on each database to obtain the used plugin list:

   select extname from pg_extension;

5. Select a target version that contains all plugins based on the used plugin list.

   For details about the plugins supported by different RDS for PostgreSQL versions, see Supported Plugins.

6. Create a parameter template that is compatible with the source version by referring to Creating a Parameter Template.
7. Create an RDS for PostgreSQL instance running the target version.
   • For details on how to create a DB instance, see Buying a DB Instance.
   • The region, AZ, VPC, subnet, and security group of the target instance are the same as those of the source instance.
8. On the ECS prepared in 2, use psql to connect to the target instance and check that the connection is successful.

Procedure

Perform the following operations on the prepared ECS.

1. Use psql to connect to the source instance and run the following SQL statement to obtain the database list:

   postgres=# \l

2. Use psql to connect to the target instance and run the following SQL statement to check whether all databases obtained in 1 exist on the target instance:

   postgres=# \l

   • If yes, go to 3.
   • If no, run the following SQL statement to create databases that does not exist on the target instance and go to 3.

     postgres=# create database my_target_db;

     

     • The template libraries template0 and template1 do not need to be migrated.
     • The postgres database is created by default and does not need to be migrated unless it stores service data.

3. Use pg_dump to dump the source instance and use pg_restore to restore data to the target instance. Repeat 3 to 4 on each service database.
   • For versions other than RDS for PostgreSQL 11, run the following dump command:

     pg_dump -Fc -v --host=source_IP --port=source_port --username=my_user --dbname=my_source_db | pg_restore -v --no-owner --host=target_IP --port=target_port --username=my_user --dbname=my_target_db

   • For RDS for PostgreSQL 11, run the following dump command:

     pg_dump -Fc -v --host=source_IP --port=source_port -Ndbms_lob -Ndbms_output -Ndbms_random -Nsys -Nutl_raw -Npg_catalog --username=my_user --dbname=my_source_db | pg_restore -v --no-owner --host=target_IP --port=target_port --username=my_user --dbname=my_target_db

   

   • The login user using pg_dump must have the permission to access all objects in the database.
   • The login user using pg_restore must have all operation permissions on the database.
   • For details about how to grant permissions, see GRANT.
   • If the pg_dump command uses the -N parameter, blobs will not be exported.
   • If the pg_dump command uses the -Fc parameter, the exported file is in binary format. To export SQL files, use the -Fp parameter.

4. After a database is migrated, test services on the target database to ensure that the services are running properly on it.
5. Check that services are running properly on the target databases. Then, switch services to the target instance and delete the source instance.