Tue 15 October, 2019
repmgr 5.0 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.
repmgr now parses configuration files in the same way that PostgreSQL itself does, which means some files used with earlier repmgr versions may need slight modification before they can be used with repmgr 5 and later.
The main change is that string parameters should always be enclosed in single quotes.
For example, in repmgr 4.4 and earlier, the following repmgr.conf
entry was valid:
conninfo=host=node1 user=repmgr dbname=repmgr connect_timeout=2
This must now be changed to:
conninfo='host=node1 user=repmgr dbname=repmgr connect_timeout=2'
Note that simple string identifiers (e.g. node_name=node1)
may remain unquoted, though we recommend always enclosing
strings in single quotes.
Additionally, leading/trailing white space between single quotes will no longer be trimmed; the entire string between single quotes will be taken literally.
Strings enclosed in double quotes (e.g. node_name="node1")
will now be rejected; previously they were accepted, but the double quotes were
interpreted as part of the string, which was a frequent cause of confusion.
This syntax matches that used by PostgreSQL itself.
Some "repmgr daemon ..." commands have been renamed to
"repmgr service ..." as they have a cluster-wide effect
and to avoid giving the impression they affect only the local repmgr daemon.
The following commands are affected:
repmgr daemon pause
(now repmgr service pause)
repmgr daemon unpause
(now repmgr service unpause)
repmgr daemon status
(now repmgr service status)
The "repmgr daemon ..." form will still be accepted
for backwards compatibility.
The following command line options, which have been deprecated since repmgr 3.3 (and which no longer had any effect other than to generate a warning about their use) have been removed:
--data-dir--no-conninfo-password--recovery-min-apply-delay
Support for PostgreSQL 12 added.
Beginning with PostgreSQL 12, replication configuration has been integrated
into the main PostgreSQL configuraton system and the conventional
recovery.conf file is no longer valid.
repmgr has been modified to be compatible with this change.
repmgr additionally takes advantage of the new pg_promote()
function, which enables a standby to be promoted to primary using an SQL
command.
For an overview of general changes to replication configuration, see this blog entry: Replication configuration changes in PostgreSQL 12
The repmgr configuration file is now parsed using
flex, meaning it will be parsed in
the same way as PostgreSQL parses its own configuration
files.
This makes configuration file parsing more robust and consistent.
See item Configuration file parsing has been made stricter for details.
repmgr standby clone:
checks for availability of the repmgr extension on the upstream node have
been improved and error messages improved.
When executing repmgr remotely, if the repmgr log level was explicitly
provided (with -L/--log-level), that log level
will be passed to the remote repmgr.
This makes it possible to return log output when executing repmgr
remotely at a different level to the one defined in the remote
repmgr's repmgr.conf.
This is particularly useful when DEBUG output is required.
Check role membership when trying to read pg_settings.
Previously repmgr assumed only superusers could read pg_settings,
but from PostgreSQL 10, all members of the roles pg_read_all_settings
or pg_monitor are permitted to do this as well.
repmgrd: Fix handling of upstream node change check.
repmgrd has a check to see if the upstream node has unexpectedly changed, e.g. if the repmgrd service is paused and the PostgreSQL instance has been pointed to another node.
However this check was relying on the node record on the local node being up-to-date, which may not be the case immediately after a failover, when the node is still replaying records updated prior to the node's own record being updated. In this case it will mistakenly assume the node is following the original primary and attempt to restart monitoring, which will fail as the original primary is no longer available.
To prevent this, the node's record on the upstream node is checked
to see if the reported upstream node_id matches
the expected node_id. GitHub #587/#588.