Thu 27 June, 2019
repmgr 4.4 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.
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 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).
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.
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 provided 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.
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.
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