Release notesRelease notes
Changes to each &repmgr; release are documented in the release notes.
Please read the release notes for all versions between
your current version and the version you are plan to upgrade to
before performing an upgrade, as there may be version-specific upgrade steps.
See also: Release 4.1.1??? ??? ??, 2018repmgrd enhancementsrepmgrd: always reopen the log file after
receiving SIGHUP. Previously this only happened if
a configuration file change was detected.
(GitHub #485).
repmgrd: report version number after
logger initialisation. (GitHub #487).
Bug fixesrepmgrd: fix startup on witness node when local data is stale. (GitHub #488, #489).
Release 4.1.0Tue July 31, 2018
&repmgr; 4.1.0 introduces some changes to repmgrd
behaviour and some additional configuration parameters.
This release can be installed as a simple package upgrade from repmgr 4.0 ~ 4.0.6.
The following post-upgrade steps must be carried out:
Execute ALTER EXTENSION repmgr UPDATE
on the primary server in the database where &repmgr; is installed.
repmgrd must be restarted on all nodes where it is running.
A restart of the PostgreSQL server is not required
for this release (unless upgrading from repmgr 3.x).
See for more details.
Configuration changes are backwards-compatible and no changes to
repmgr.conf are required. However users should
review the changes listed below.
Repository changes
Coinciding with this release, the 2ndQuadrant repository structure has changed.
See section for details, particularly
if you are using a RPM-based system.
Configuration file changes
Default for is now .
This produces additional informative log output, without creating excessive additional
log file volume, and matches the setting assumed for examples in the documentation.
(GitHub #470).
recovery_min_apply_delay now accepts a minimum value
of zero (GitHub #448).
repmgr enhancementsrepmgr: always exit with an error if an unrecognised
command line option is provided. This matches the behaviour of other PostgreSQL
utilities such as psql. (GitHub #464).
repmgr: add option to suppress non-error
output. (GitHub #468).
repmgr cluster show,
repmgr node check and
repmgr node status
return non-zero exit code if node status issues detected. (GitHub #456).
Add output option for
repmgr cluster event.
(GitHub #471).
repmgr witness unregister
can be run on any node, by providing the ID of the witness node with .
(GitHub #472).
repmgr standby switchover
will refuse to run if an exclusive backup is taking place on the current primary.
(GitHub #476).
repmgrd enhancementsrepmgrd: create a PID file by default
(GitHub #457). For details, see .
repmgrd: daemonize process by default.
In case, for whatever reason, the user does not wish to daemonize the
process, provide .
(GitHub #458).
Bug fixesrepmgr standby register --wait-sync:
fix behaviour when no timeout provided.
repmgr cluster cleanup:
add missing help options. (GitHub #461/#462).
Ensure witness node follows new primary after switchover. (GitHub #453).
repmgr node check and
repmgr node status:
fix witness node handling. (GitHub #451).
When using repmgr standby clone
with and replication slots, ensure
primary_slot_name is set correctly. (GitHub #474).
Release 4.0.6Thu June 14, 2018
&repmgr; 4.0.6 contains a number of bug fixes and usability enhancements.
We recommend upgrading to this version as soon as possible.
This release can be installed as a simple package upgrade from repmgr 4.0 ~ 4.0.5;
repmgrd (if running) should be restarted. See
for more details.
Usability enhancementsrepmgr cluster crosscheck and
repmgr cluster matrix:
return non-zero exit code if node connection issues detected (GitHub #447)
repmgr standby clone:
Improve handling of external configuration file copying, including consideration in
check
(GitHub #443)
When using , force log level to INFO
to ensure output will always be displayed
(GitHub #441)
repmgr standby clone:
Improve documentation of mode
(GitHub #438)
repmgr standby clone:
Don't require presence of user parameter in conninfo string
(GitHub #437)
Bug fixesrepmgr witness register:
prevent registration of a witness server with the same name as an existing node
repmgr standby follow:
check node has actually connected to new primary before reporting success
(GitHub #444)
repmgr node rejoin:
Fix bug when parsing parameter
(GitHub #442)
repmgrd: ensure local node is counted as quorum member
(GitHub #439)
Release 4.0.5Wed May 2, 2018
&repmgr; 4.0.5 contains a number of usability enhancements related to
pg_rewind usage, recovery.conf
generation and (in repmgrd) handling of various
corner-case situations, as well as a number of bug fixes.
Usability enhancements
Various documentation improvements, with particular emphasis on
the importance of setting appropriate service commands
instead of relying on pg_ctl.
Poll demoted primary after restart as a standby during a switchover operation (GitHub #408).
Add configuration parameter (GitHub #424).
Add sanity check if not supplied when executing
(GitHub #395).
Enable pg_rewind to be used with
PostgreSQL 9.3/9.4 (GitHub #413).
When generating replication connection strings, set dbname=replication
if appropriate (GitHub #421).
Enable provision of in recovery.conf
(GitHub #416).
Actively check for node to rejoin cluster (GitHub #415).
repmgrd: set connect_timeout=2 (if not explicitly set)
when pinging a server.
Bug fixes
Fix display of conninfo parsing error messages.
Fix minimum accepted value for degraded_monitoring_timeout (GitHub #411).
Fix superuser password handling (GitHub #400)
Fix parsing of archive_ready_critical configuration file parameter (GitHub #426).
Fix repmgr cluster crosscheck
output (GitHub #389)
Fix memory leaks in witness code (GitHub #402).
repmgrd: handle pg_ctl promote timeout (GitHub #425).
repmgrd: handle failover situation with only two nodes in the primary
location, and at least one node in another location (GitHub #407).
repmgrd: prevent standby connection handle from going stale.
Release 4.0.4Fri Mar 9, 2018
&repmgr; 4.0.4 contains some bug fixes and and a number of
usability enhancements related to logging/diagnostics,
event notifications and pre-action checks.
This release can be installed as a simple package upgrade from repmgr 4.0 ~ 4.0.3;
repmgrd (if running) should be restarted. See
for more details.
It is not possible to perform a switchover where the demotion candidate is
running &repmgr; 4.0.2 or lower; all nodes should be upgraded to the latest version (4.0.4).
This is due to additional checks introduced in 4.0.3 which require the presence of
4.0.3 or later versions on all nodes.
Usability enhancements
add repmgr standby clone --recovery-conf-only
option to enable integration of a standby cloned from another source into a &repmgr; cluster (GitHub #382)
remove restriction on using replication slots when cloning from a Barman server (GitHub #379)
make repmgr standby promote
timeout values configurable (GitHub #387)
add missing options to main --help output (GitHub #391, #392)
Bug fixes
ensure repmgr node rejoin
honours the option (GitHub #383)
improve replication slot warnings generated by
repmgr node status
(GitHub #385)
fix --superuser handling when cloning a standby (GitHub #380)
repmgrd: improve detection of status change from primary to
standby
repmgrd: improve reconnection to the local node after a
failover (previously a connection error due to the node starting up was being
interpreted as the node being unavailable)
repmgrd: when running on a witness server, correctly connect
to new primary after a failover
repmgrd: add event notification
repmgrd_shutdown (GitHub #393)
Release 4.0.3Thu Feb 15, 2018
&repmgr; 4.0.3 contains some bug fixes and and a number of
usability enhancements related to logging/diagnostics,
event notifications and pre-action checks.
This release can be installed as a simple package upgrade from repmgr 4.0 ~ 4.0.2;
repmgrd (if running) should be restarted.
It is not possible to perform a switchover where the demotion candidate is
running &repmgr; 4.0.2 or lower; all nodes should be upgraded to 4.0.3. This is due
to additional checks introduced in 4.0.3 which require the presence of
4.0.3 or later versions on all nodes.
Usability enhancements
improve repmgr standby switchover
behaviour when pg_ctl is used to control the server and logging output is
not explicitly redirected
improve repmgr standby switchover
log messages and provide new exit code ERR_SWITCHOVER_INCOMPLETE when old primary could
not be shut down cleanly
add check to verify the demotion candidate can make a replication connection to the
promotion candidate before executing a switchover (GitHub #370)
add check for sufficient walsenders and replication slots on the promotion candidate before executing
repmgr standby switchover
(GitHub #371)
add --dry-run mode to repmgr standby follow
(GitHub #368)
provide information about the primary node for
repmgr standby register and
repmgr standby follow event notifications (GitHub #375)
add standby_register_sync event notification, which is fired when
repmgr standby register
is run with the option and the new or updated standby node
record has synchronised to the standby (GitHub #374)
when running repmgr cluster show,
if any node is unreachable, output the error message encountered in the list of warnings
(GitHub #369)
Bug fixes
ensure an inactive data directory can be overwritten when
cloning a standby (GitHub #366)
repmgr node status
upstream node display fixed (GitHub #363)
repmgr primary unregister:
clarify usage and fix --help output (GitHub #373)
parsing of pg_basebackup_options fixed (GitHub #376)
ensure the pg_subtrans directory is created when cloning a
standby in Barman mode
repmgr witness register:
fix primary node check (GitHub #377).
Release 4.0.2Thu Jan 18, 2018
&repmgr; 4.0.2 contains some bug fixes and small usability enhancements.
This release can be installed as a simple package upgrade from &repmgr; 4.0.1 or 4.0;
repmgrd (if running) should be restarted.
Usability enhancements
Recognize the / option for
repmgr cluster event to hide
the Details column (GitHub #360)
Add "--wait-start" option for
repmgr standby register
(GitHub #356)
Add %p event notification parameter
for repmgr standby switchoverBug fixes
Add missing -W option to getopt_long() invocation (GitHub #350)
Automatically create slot name if missing (GitHub #343)
Fixes to parsing output of remote repmgr invocations (GitHub #349)
When registering BDR nodes, automatically create missing connection replication set (GitHub #347)
Handle missing node record in repmgr node rejoin
(GitHub #358)
Documentation
The documentation can now be built as a single HTML file (GitHub pull request #353)
Release 4.0.1Wed Dec 13, 2017
&repmgr; 4.0.1 is a bugfix release.
Bug fixes
ensure correct return codes are returned for
repmgr node check --action= operations
(GitHub #340)
Fix when repmgr schema not set in search path
(GitHub #341)
When using --force-rewind with
delete any replication slots copied by pg_rewind
(GitHub #334)
Only perform sanity check on accessibility of configuration files outside
the data directory when --copy-external-config-files
provided (GitHub #342)
Initialise "voting_term" table in application, not extension SQL
(GitHub #344)
Release 4.0.0Tue Nov 21, 2017
repmgr 4.0 is an entirely new version of &repmgr;, implementing &repmgr;
as a native PostgreSQL extension, adding new and improving existing features,
and making &repmgr; more user-friendly and intuitive to use. The new code base
will make it easier to add additional functionality for future releases.
With the new version, the opportunity has been taken to
make some changes in the way &repmgr; is set up and
configured. In particular changes have been made to some
configuration file settings consistency for and clarity.
Changes are covered in detail below
To standardise terminology, from this release primary is used to
denote the read/write node in a streaming replication cluster. master
is still accepted as an alias for &repmgr; commands
(e.g. repmgr master register).
For detailed instructions on upgrading from repmgr 3.x, see .
Features and improvementsimproved switchover:
the switchover process has been improved and streamlined,
speeding up the switchover process and can also instruct other standbys
to follow the new primary once the switchover has completed. See
for more details.
"--dry-run" option: many &repmgr; commands now provide
a --dry-run option which will execute the command as far
as possible without making any changes, which will enable possible issues
to be identified before the intended operation is actually carried out.
easier upgrades: &repmgr; is now implemented as a native
PostgreSQL extension, which means future upgrades can be carried out by
installing the upgraded package and issuing
ALTER EXTENSION repmgr UPDATE.
improved logging output:
&repmgr; (and repmgrd) now provide more explicit
logging output giving a better picture of what is going on. Where appropriate,
DETAIL and HINT log lines provide additional
detail and suggestions for resolving problems. Additionally, repmgrd
now emits informational log lines at regular, configurable intervals
to confirm that it's running correctly and which node(s) it's monitoring.
automatic configuration file location in packages:
Many operating system packages place the &repmgr; configuration files
in a version-specific subdirectory, e.g. /etc/repmgr/9.6/repmgr.conf;
&repmgr; now makes it easy for package maintainers to provide a patch
with the actual file location, meaning repmgr.conf
does not need to be provided explicitly. This is currently the case
for 2ndQuadrant-provided .deb and .rpm packages.
monitoring and status checks:
New commands and
providing information
about a node's status and replication-related monitoring
output.
node rejoin:
New commands enables a failed
primary to be rejoined to a replication cluster, optionally using
pg_rewind to synchronise its data,
(note that pg_rewind may not be useable
in some circumstances).
automatic failover:
improved detection of node status; promotion decision based on a consensual
model, with the promoted primary explicitly informing other standbys to
follow it. The repmgrd daemon will continue
functioning even if the monitored PostgreSQL instance is down, and resume
monitoring if it reappears. Additionally, if the instance's role has changed
(typically from a primary to a standby, e.g. following reintegration of a
failed primary using ) repmgrd
will automatically resume monitoring it as a standby.
new documentation:
the existing documentation spread over multiple text files
has been consolidated into DocBook format (as used by the
main PostgreSQL project) and is now available online in
HTML format.
The DocBook files can easily be used to create versions
of the documentation in other formats such as PDF.
New command line options--dry-run: &repmgr; will attempt to perform
the action as far as possible without making any changes to the
database
--upstream-node-id: use to specify the upstream node
the standby will connect later stream from, when cloning
and registering a standby.
This replaces the configuration file parameter upstream_node.
as the upstream node is set when the standby is initially cloned, but can change
over the lifetime of an installation (due to failovers, switchovers etc.) so it's
pointless/confusing keeping the original value around in repmgr.conf.
Changed command line optionsrepmgr--replication-user has been deprecated; it has been replaced
by the configuration file option replication_user.
The value (which defaults to the user provided in the conninfo
string) will be stored in the &repmgr; metadata for use by
and .
--recovery-min-apply-delay is now a configuration file parameter
recovery_min_apply_delay, to ensure the setting does not get lost
when a standby follows a new upstream.
--no-conninfo-password is deprecated; a password included in
the environment variable PGPASSWORD will no longer be added
to primary_conninfo by default; to force the inclusion
of a password (not recommended), use the new configuration file parameter
use_primary_conninfo_password. For details, ee section
.
repmgrd--monitoring-history is deprecated and is replaced by the
configuration file option monitoring_history.
This enables the setting to be changed without having to modify system service
files.
Configuration file changesRequired settingsThe following 4 parameters are mandatory in repmgr.conf:
node_idnode_nameconninfodata_directoryRenamed settings
Some settings have been renamed for clarity and consistency:
node is now node_idname is now node_namebarman_server is now barman_hostmaster_reponse_timeout is now
async_query_timeout (to better indicate its purpose)
The following configuration file parameters have been renamed for consistency
with other parameters (and conform to the pattern used by PostgreSQL itself,
which uses the prefix log_ for logging parameters):
loglevel is now log_levellogfile is now log_filelogfacility is now log_facilityRemoved settingscluster has been removedupstream_node - see note about
--upstream-node-id aboveretry_promote_interval_secsthis is now redundant due
to changes in the failover/promotion mechanism; the new equivalent is
primary_notification_timeoutLogging changes
default value for log_level is INFO
rather than NOTICE.
new parameter log_status_interval, which causes
repmgrd to emit a status log
line at the specified interval
repmgrd
The shared library has been renamed from repmgr_funcs to
repmgr, meaning shared_preload_libraries
in postgresql.conf needs to be updated to the new name:
shared_preload_libraries = 'repmgr'