Release 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: ??? Feb ??, 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. 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 #369) add standby_register_sync event notification, which is fired when repmgr standby register is run with the --wait-sync option and the new or updated standby node record has synchronised to the standy (GitHub #374) when running repmgr cluster show, if any node is unreachable, output the error message encountered in the list of warnings (GitHub #369) 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). Thu 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. Recognize the -t/--terse 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 switchover 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) The documentation can now be built as a single HTML file (GitHub pull request #353) Wed Dec 13, 2017 &repmgr; 4.0.1 is a bugfix release. 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) Tue 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 . improved 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. --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. repmgr --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. Required settings The following 4 parameters are mandatory in repmgr.conf: node_id node_name conninfo data_directory Renamed settings Some settings have been renamed for clarity and consistency: node is now node_id name is now node_name barman_server is now barman_host master_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_level logfile is now log_file logfacility is now log_facility Removed settings cluster has been removed upstream_node - see note about --upstream-node-id above retry_promote_interval_secsthis is now redundant due to changes in the failover/promotion mechanism; the new equivalent is primary_notification_timeout Logging 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 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'