4.4.0:
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).
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.
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.
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.
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.
4.3:
repmgr: add "daemon (start|stop)" command
repmgr: add --version-number command line option
repmgr: add --compact option to "cluster show"
repmgr: cluster show - differentiate between unreachable nodes
and nodes which are running but rejecting connections
repmgr: add --dry-run option to "standby promote"
repmgr: add "node check --data-directory-config"
repmgr: prevent potential race condition in "standby switchover"
when checking received WAL location
repmgr: ensure "standby switchover" verifies repmgr can read the
data directory on the demotion candidate
repmgr: ensure "standby switchover" verifies replication connection
exists
repmgr: add sanity check for correct extension version
repmgr: ensure "witness register --dry-run" does not attempt to read node
tables if repmgr extension not installed
repmgr: ensure "standby register" fails when --upstream-node-id is the
same as the local node ID
repmgrd: check binary and extension major versions match
repmgrd: on a cascaded standby, don't fail over if "failover=manual";
repmgrd: don't consider nodes where repmgrd is not running as promotion
candidates
repmgrd: add option "connection_check_type"
repmgrd: improve witness monitoring when primary node not available
repmgrd: handle situation where a primary has unexpectedly appeared
during failover
repmgr 4.2 is a major release, with the main new feature being the ability to pause repmgrd, e.g. during planned maintenance operations. Various other usability enhancements and a couple of bug fixes are also included.
4.1.0:
Configuration file changes
* Default for log_level is now INFO. This produces additional informative log output, without creating excessive additional log file volume, and matches the setting assumed for examples in the documentation.
* recovery_min_apply_delay now accepts a minimum value of zero
repmgr enhancements
* repmgr: always exit with an error if an unrecognised command line option is provided. This matches the behaviour of other PostgreSQL utilities such as psql.
* repmgr: add -q/--quiet option to suppress non-error output.
* repmgr cluster show, repmgr node check and repmgr node status return non-zero exit code if node status issues detected.
* Add --csv output option for repmgr cluster event.
* repmgr witness unregister can be run on any node, by providing the ID of the witness node with --node-id.
* repmgr standby switchover will refuse to run if an exclusive backup is taking place on the current primary.
repmgrd enhancements
repmgrd: create a PID file by default. For details, see repmgrd's PID file.
repmgrd: daemonize process by default. In case, for whatever reason, the user does not wish to daemonize the process, provide --daemonize=false.
Bug fixes
repmgr standby register --wait-sync: fix behaviour when no timeout provided.
repmgr cluster cleanup: add missing help options.
Ensure witness node follows new primary after switchover.
repmgr node check and repmgr node status: fix witness node handling.
Based on package provided by Matthieu Guegan in joyent/pkgsrc#49
repmgr is a suite of open-source tools to manage replication and failover
within a cluster of PostgreSQL servers. It enhances PostgreSQL's built-in
replication capabilities with utilities to set up standby servers, monitor
replication, and perform administrative tasks such as failover or
switchover operations.
