repmgr 4.3 Documentation | |||
---|---|---|---|
Prev | Up | Chapter 10. Upgrading repmgr | Next |
From version 4, repmgr consists of three elements:
With minor releases, usually changes are only made to the repmgr and repmgrd executables. In this case, the upgrade is quite straightforward, and is simply a case of installing the new version, and restarting repmgrd (if running).
For major releases, the repmgr PostgreSQL extension will need to be updated to the latest version. Additionally, if the shared library module has been updated (this is sometimes, but not always the case), PostgreSQL itself will need to be restarted on each node.
Important: Always check the release notes for every release as they may contain upgrade instructions particular to individual versions.
The process for installing minor version upgrades is quite straightforward:
Note: Some packaging systems (e.g. Debian/Ubuntu may restart repmgrd as part of the package upgrade process.
Minor version upgrades can be performed in any order on the nodes in the replication cluster.
A PostgreSQL restart is not required for minor version upgrades.
Note: The same repmgr "major version" (e.g. 4.2) must be installed on all nodes in the replication cluster. While it's possible to have differing repmgr "minor versions" (e.g. 4.2.1) on different nodes, we strongly recommend updating all nodes to the latest minor version.
"major version" upgrades need to be planned more carefully, as they may include changes to the repmgr metadata (which need to be propagated from the primary to all standbys) and/or changes to the shared object file used by repmgrd (which require a PostgreSQL restart).
With this in mind,
Stop repmgrd (if in use) on all nodes where it is running.
Disable the repmgrd service on all nodes where it is in use; this is to prevent packages from prematurely restarting repmgrd.
Install the updated package (or compile the updated source) on all nodes.
If running a systemd-based Linux distribution, execute (as root, or with appropriate sudo permissions):
systemctl daemon-reload
If the repmgr shared library module has been updated (check the release notes!), restart PostgreSQL, then repmgrd (if in use) on each node, The order in which this is applied to individual nodes is not critical, and it's also fine to restart PostgreSQL on all nodes first before starting repmgrd.
Note that if the upgrade requires a PostgreSQL restart, repmgrd will only function correctly once all nodes have been restarted.
On the primary node, execute
ALTER EXTENSION repmgr UPDATE
in the database where repmgr is installed.
Reenable the repmgrd service on all nodes where it is in use, and ensure it is running.
Tip: If the repmgr upgrade requires a PostgreSQL restart, combine the repmgr upgrade with a PostgreSQL minor version upgrade, which will require a restart in any case. New PostgreSQL minor version are usually released every couple of months.
From repmgr 4.2, once the upgrade is complete, execute the repmgr daemon status command (on any node) to show an overview of the status of repmgrd on all nodes.