Relational Database ServiceRelational Database Service

Compute
Elastic Cloud Server
Bare Metal Server
Auto Scaling
Image Management Service
Dedicated Host
FunctionGraph
Networking
Virtual Private Cloud
Elastic IP
Elastic Load Balance
NAT Gateway
Direct Connect
Virtual Private Network
Domain Name Service
VPC Endpoint
Cloud Connect
Enterprise Switch
Security & Compliance
Anti-DDoS
Web Application Firewall
Host Security Service
Data Encryption Workshop
Database Security Service
Advanced Anti-DDoS
Data Security Center
Container Guard Service
Situation Awareness
Managed Threat Detection
Compass
Cloud Certificate Manager
Anti-DDoS Service
Databases
Relational Database Service
Document Database Service
Data Admin Service
Data Replication Service
GaussDB NoSQL
GaussDB(for MySQL)
Distributed Database Middleware
GaussDB(for openGauss)
Developer Services
ServiceStage
Distributed Cache Service
Simple Message Notification
Application Performance Management
Application Operations Management
Blockchain Service
API Gateway
Cloud Performance Test Service
Distributed Message Service for Kafka
Distributed Message Service for RabbitMQ
Distributed Message Service for RocketMQ
Cloud Service Engine
DevCloud
ProjectMan
CodeHub
CloudRelease
CloudPipeline
CloudBuild
CloudDeploy
Cloud Communications
Message & SMS
Cloud Ecosystem
Marketplace
Partner Center
User Support
My Account
Billing Center
Cost Center
Resource Center
Enterprise Management
Service Tickets
HUAWEI CLOUD (International) FAQs
ICP License Service
Support Plans
Customer Operation Capabilities
Partner Support Plans
Professional Services
enterprise-collaboration
Meeting
IoT
IoT
Intelligent EdgeFabric
DeveloperTools
SDK Developer Guide
API Request Signing Guide
Terraform
Koo Command Line Interface
Updated at: Apr 02, 2022 GMT+08:00

Upgrading the Major Version of a DB Instance

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 Instance Management 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.

    For details on how to create and connect to an ECS, see How Can I Create and Connect to 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 installed on the RDS for PostgreSQL database server. The PostgreSQL database 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 Enhanced Edition and 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 Enhanced Edition and 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.

  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.

Did you find this page helpful?

Failed to submit the feedback. Please try again later.

Which of the following issues have you encountered?







Please complete at least one feedback item.

Content most length 200 character

Content is empty.

OK Cancel