repmgr 4.2 Documentation
Prev	Up	Chapter 11. Upgrading repmgr	Next

11.1. Upgrading repmgr 4.x and later

From version 4, repmgr consists of three elements:

the repmgr and repmgrd executables
the objects for the repmgr PostgreSQL extension (SQL files for creating/updating repmgr metadata, and the extension control file)
the shared library module used by repmgrd which is resident in the PostgreSQL backend

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.

11.1.1. Upgrading a minor version release

The process for installing minor version upgrades is quite straightforward:

install the new repmgr version
restart repmgrd on all nodes where it is running

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.

11.1.2. Upgrading a major version release

"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.

11.1.3. Checking repmgrd status after an upgrade

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.