A.6. Release 4.3

A.6.1. repmgr client enhancements
A.6.2. repmgrd enhancements
A.6.3. Bug fixes

Tue April 2, 2019

repmgr 4.3 is a major release.

For details on how to upgrade an existing repmgr installation, 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.6.1. repmgr client enhancements

  • repmgr standby follow: option --upstream-node-id can now be used to specify another standby to follow.

  • repmgr standby follow: verify that it is actually possible to follow another node.

  • repmgr node rejoin: verify that it is actually possible to attach the node to the current primary.

  • New commands repmgr daemon start and repmgr daemon stop: these provide a standardized way of starting and stopping repmgrd. GitHub #528.

    Note

    These commands require the configuration file settings repmgrd_service_start_command and repmgrd_service_stop_command in repmgr.conf to be set.

  • repmgr daemon status additionally displays the node priority and the interval (in seconds) since the repmgrd instance last verified its upstream node was available.

  • Add --compact option to repmgr cluster show (GitHub #521).

    This makes it easier to copy the output into emails, chats etc. as a compact table.

  • repmgr cluster show: differentiate between unreachable nodes and nodes which are running but rejecting connections.

    This makes it possible to see whether a node is unreachable at network level, or if it is running but rejecting connections for some reason.

  • Add --dry-run to repmgr standby promote (GitHub #522).

  • repmgr --version-number outputs the "raw" repmgr version number (e.g. 40300). This is intended for use by scripts etc. requiring an easily parseable representation of the repmgr version.

  • repmgr node check --data-directory-config option added; this is to confirm repmgr is correctly configured. GitHub #523.

  • Add check to repmgr standby switchover to ensure the data directory on the demotion candidate is configured correctly in repmgr.conf. This is to ensure that repmgr, when remotely executed on the demotion candidate, can correctly verify that PostgreSQL on the demotion candidate was shut down cleanly. GitHub #523.

A.6.2. repmgrd enhancements

  • repmgrd will no longer consider nodes where repmgrd is not running as promotion candidates.

    Previously, if repmgrd was not running on a node, but that node qualified as the promotion candidate, it would never be promoted due to the absence of a running repmgrd.

  • Add option connection_check_type to enable selection of the method repmgrd uses to determine whether the upstream node is available.

    Possible values are ping (default; uses PQping() to determine server availability), connection (attempst to make a new connection to the upstream node), and query (determines server availability by executing an SQL statement on the node via the existing connection).

  • New configuration option failover_validation_command to allow an external mechanism to validate the failover decision made by repmgrd.

  • New configuration option standby_disconnect_on_failover to force standbys to disconnect their WAL receivers before making a failover decision.

  • In a failover situation, repmgrd will not attempt to promote a node if another primary has already appeared (e.g. by being promoted manually). GitHub #420.

A.6.3. Bug fixes

  • repmgr cluster show: fix display of node IDs with multiple digits.

  • ensure repmgr primary unregister behaves correctly when executed on a witness server. GitHub #548.

  • ensure repmgr standby register fails when --upstream-node-id is the same as the local node ID.

  • repmgr: when executing repmgr standby clone, recheck primary/upstream connection(s) after the data copy operation is complete, as these may have gone away.

  • repmgr: when executing repmgr standby switchover, prevent escaping issues with connection URIs when executing repmgr node rejoin on the demotion candidate. GitHub #525.

  • repmgr: when executing repmgr standby switchover, verify the standby (promotion candidate) is currently attached to the primary (demotion candidate). GitHub #519.

  • repmgr: when executing repmgr standby switchover, avoid a potential race condition when comparing received WAL on the standby to the primary's shutdown location, as the standby's walreceiver may not have yet flushed all received WAL to disk. GitHub #518.

  • repmgr: when executing repmgr witness register, check the node to connected is actually the primary (i.e. not the witness server). GitHub #528.

  • repmgr node check will only consider physical replication slots, as the purpose of slot checks is to warn about potential issues with streaming replication standbys which are no longer attached.

  • repmgrd: on a cascaded standby, don't fail over if failover=manual. GitHub #531.