18.6. Upgrading a Postgres Pro Cluster #
This section discusses how to upgrade your database from one Postgres Pro Shardman release to a newer one. It is best to review the Release Notes before an upgrade and look for any changes that may cause issues for your application. You can proceed to upgrade if there are no potential issues.
The process of updating a Postgres Pro Shardman consists of several steps that must be performed sequentially:
Upgrade Postgres Pro Shardman packages.
Restart all Postgres Pro Shardman services and database instances.
Upgrade database shardman extension.
18.6.1. Upgrade Packages #
18.6.1.1. APT-based Systems #
To upgrade packages, typically run the following command:
$apt update && apt --only-upgrade install shardman-tools shardman-services postgrespro-sdm-17-contrib postgrespro-sdm-17-server
or upgrade all packages:
$apt update && apt upgrade
Check that all packages have been updated on each node:
$dpkg -l | grep -E '(postgrespro|shardman)'
18.6.1.2. RPM-based systems #
To upgrade packages, typically run the following command:
$yum update shardman-tools shardman-services postgrespro-sdm-17-contrib postgrespro-sdm-17-server
or upgrade all packages:
$yum update
Check that all packages have been updated on each node:
$yum list --installed | grep -E '(postgrespro|shardman)'
18.6.2. Restart Postgres Pro Shardman Services and Database Instances #
After updating the packages, you need to restart all cluster services. It can be done with a single shardmanctl restart command:
$shardmanctl --cluster-name cluster0 --store-endpoints http://etcd1:2379,http://etcd2:2379,http://etcd3:2379 restart
You can skip the --cluster-name and --store-endpoints options by setting the SDM_CLUSTER_NAME and SDM_STORE_ENDPOINTS environment variables as in the example below:
export SDM_STORE_ENDPOINTS=http://etcd1:2379,http://etcd2:2379,http://etcd3:2379
export SDM_CLUSTER_NAME=cluster0
18.6.3. Upgrade the Extension #
After restarting services of the cluster, you should update the server extensions by running the following command:
$shardmanctl --cluster-name cluster0 --store-endpoints http://etcd1:2379,http://etcd2:2379,http://etcd3:2379 upgrade
In the case when the shardman extension version and server library version are different, distributed queries and Postgres Pro Shardman DDL will not work.
Postgres Pro Shardman extensions try to ensure that they do not communicate with incompatible software. Incompatibilities can arise for several reasons: the shardman shared library version does not match the extension version or the remote server version does not match the local server version. In case when the extension and library versions mismatch, Postgres Pro Shardman cannot modify its metadata and will refuse to perform operations on global objects until the extension is updated. In case when the remote server version does not match the local server version or when they belong to different clusters, Postgres Pro Shardman will refuse to communicate with the server.
18.6.4. Upgrading Data via Replication #
It is also possible to use logical replication methods to create a standby server with the updated version of Postgres Pro. This is possible because logical replication supports replication between different major versions of Postgres Pro. The standby can be on the same computer or a different computer. Once it has synced up with the primary server (running the older version of Postgres Pro), you can switch primaries and make the standby the primary and shut down the older database instance. Such a switch-over results in only several seconds of downtime for an upgrade.
This method of upgrading can be performed using the built-in logical replication facilities as well as using external logical replication systems such as pglogical, Slony, Londiste, and Bucardo.