A.1. Release 4.4

A.1.1. repmgr client enhancements
A.1.2. repmgrd enhancements
A.1.3. Bug fixes
A.1.4. Other

27 June, 2019

repmgr 4.4 is a major release.

For details on how to upgrade an existing repmgr instrallation, see documentation section Upgrading a major version release.

If repmgrd is in use, a PostgreSQL restart is required; in that case we suggest combining this repmgr upgrade with the next PostgreSQL minor release, which will require a PostgreSQL restart in any case.

Important

On Debian-based systems, including Ubuntu, if using repmgrd please ensure that in the file /etc/init.d/repmgrd, the parameter REPMGRD_OPTS contains "--daemonize=false", e.g.:

# additional options
REPMGRD_OPTS="--daemonize=false"

For further details, see repmgrd configuration on Debian/Ubuntu.

A.1.1. repmgr client enhancements

  • repmgr standby clone: prevent a standby from being cloned from a witness server (PostgreSQL 9.6 and later only).

  • repmgr witness register: prevent a witness server from being registered on the replication cluster primary server (PostgreSQL 9.6 and later only).

    Registering a witness on the primary node would defeat the purpose of having a witness server, which is intended to remain running even if the cluster's primary goes down.

  • repmgr standby follow: note that an active, reachable cluster primary is required for this command; and provide a more helpful error message if no reachable primary could be found.

  • repmgr: when executing repmgr standby switchover, if --siblings-follow is not supplied, list all nodes which repmgr considers to be siblings (this will include the witness server, if in use), and which will remain attached to the old primary.

  • repmgr: when executing repmgr standby switchover, ignore nodes which are unreachable and marked as inactive. Previously it would abort if any node was unreachable, as that means it was unable to check if repmgrd is running.

    However if the node has been marked as inactive in the repmgr metadata, it's reasonable to assume the node is no longer part of the replication cluster and does not need to be checked.

  • repmgr standby switchover and repmgr standby promote: when executing with the --dry-run option, continue checks as far as possible even if errors are encountered.

  • repmgr standby promote: add --siblings-follow (similar to repmgr standby switchover).

    Note

    If using repmgrd, when invoking repmgr standby promote (either directly via the promote_command, or in a script called via promote_command), --siblings-follow must not be included as a command line option for repmgr standby promote.

  • repmgr standby switchover: add --repmgrd-force-unpause to unpause all repmgrd instances after executing a switchover. This will ensure that any repmgrd instances which were paused before the switchover will be unpaused.

  • repmgr daemon status: make output similar to that of repmgr cluster show for consistency and to make it easier to identify nodes not in the expected state.

  • repmgr cluster show: display each node's timeline ID (PostgreSQL 9.6 and later only).

  • repmgr cluster show and repmgr daemon status: show the upstream node name as reported by each individual node - this helps visualise situations where the cluster is in an unexpected state, and provide a better idea of the actual cluster state.

    For example, if a cluster has divided somehow and a set of nodes are following a new primary, when running either of these commands, repmgr will now show the name of the primary those nodes are actually following, rather than the now outdated node name recorded on the other side of the "split". A warning will also be issued about the unexpected situation.

  • repmgr cluster show and repmgr daemon status: check if a node is attached to its advertised upstream node, and issue a warning if the node is not attached.

A.1.2. repmgrd enhancements

  • On the primary node, repmgrd is now able to monitor standby connections and, if the number of nodes connected falls below a certain (configurable) value, execute a custom script.

    This provides an additional method for fencing an isolated primary node, and/or taking other action if one or more standys become disconnected.

    See section Monitoring standby disconnections on the primary node for more details.

  • In a failover situation, repmgrd nodes on the standbys of the failed primary are now able confirm among themselves that none can still see the primary before continuing with the failover.

    The repmgr.conf option primary_visibility_consensus must be set to true to enable this functionality.

    See section Primary visibility consensus for more details.

A.1.3. Bug fixes

  • Ensure BDR2-specific functionality cannot be used on BDR3 and later.

    The BDR support present in repmgr is for specific BDR2 use cases.

  • repmgr: when executing repmgr standby clone in --dry-run mode, ensure provision of the --force option does not result in an existing data directory being modified in any way.

  • repmgr: when executing repmgr primary register with the --force option, if another primary record exists but the associated node is unreachable (or running as a standby), set that node's record to inactive to enable the current node to be registered as a primary.

  • repmgr: when executing repmgr standby clone with the --upstream-conninfo, ensure that application_name is set correctly in primary_conninfo.

  • repmgr: when executing repmgr standby switchover, don't abort if one or more nodes are not reachable and they are marked as inactive.

  • repmgr: canonicalize the data directory path when parsing the configuration file, so the provided path matches the path PostgreSQL reports as its data directory. Otherwise, if e.g. the data directory is configured with a trailing slash, repmgr node check --data-directory-config will return a spurious error.

  • repmgrd: fix memory leak which occurs while the monitored PostgreSQL node is not running.

A.1.4. Other

  • The repmgr documentation has been converted to DocBook XML format, as currently used by the main PostgreSQL project. This means it can now be built against any PostgreSQL version from 9.5 (previously it was not possible to build the documentation against PostgreSQL 10 or later), and makes it easier to provide the documentation in other formats such as PDF.

    For further details see: Building repmgr documentation