Tue April 2, 2019
repmgr 4.3 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.
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.
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.
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.
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.
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.