FAQ (Frequently Asked Questions) &repmgr; 4 is a complete rewrite of the existing &repmgr; code base and implements &repmgr; as a PostgreSQL extension. It supports all PostgreSQL versions from 9.3 (although some &repmgr; features are not available for PostgreSQL 9.3 and 9.4). &repmgr; 3.x builds on the improved replication facilities added in PostgreSQL 9.3, as well as improved automated failover support via repmgrd, and is not compatible with PostgreSQL 9.2 and earlier. We recommend upgrading to &repmgr; 4, as the &repmgr; 3.x series will no longer be actively maintained. repmgr 2.x supports PostgreSQL 9.0 ~ 9.3. While it is compatible with PostgreSQL 9.3, we recommend using repmgr 4.x. Replication slots, introduced in PostgreSQL 9.4, ensure that the primary server will retain WAL files until they have been consumed by all standby servers. This makes WAL file management much easier, and if used `repmgr` will no longer insist on a fixed minimum number (default: 5000) of WAL files being retained. However this does mean that if a standby is no longer connected to the primary, the presence of the replication slot will cause WAL files to be retained indefinitely. Normally at least same number as the number of standbys which will connect to the node. Note that changes to max_replication_slots require a server restart to take effect, and as there is no particular penalty for unused replication slots, setting a higher figure will make adding new nodes easier. Before PostgreSQL 10, hash indexes were not WAL logged and are therefore not suitable for use in streaming replication in PostgreSQL 9.6 and earlier. See the PostgreSQL documentation for details. From PostgreSQL 10, this restriction has been lifted and hash indexes can be used in a streaming replication cluster. Yes, any existing PostgreSQL server which is part of the same replication cluster can be registered with &repmgr;. There's no requirement for a standby to have been cloned using &repmgr;. This is a two-stage process. First, the failed primary's data directory must be re-synced with the current primary; secondly the failed primary needs to be re-registered as a standby. In PostgreSQL 9.5 and later, it's possible to use pg_rewind to re-synchronise the existing data directory, which will usually be much faster than re-cloning the server. However pg_rewind can only be used if PostgreSQL either has wal_log_hints enabled, or data checksums were enabled when the cluster was initialized. &repmgr; provides the command repmgr node rejoin which can optionally execute pg_rewind; see the documentation for details. If pg_rewind cannot be used, then the data directory will have to be re-cloned from scratch. Execute repmgr standby clone with the --dry-run option; this will report any configuration problems which need to be rectified. Use the command line option --copy-external-config-files. For more details see . No, the repmgr shared library is only needed when running repmgrd. If you later decide to run repmgrd, you just need to add shared_preload_libraries = 'repmgr' and restart PostgreSQL. repmgr andrepmgrd need to be able to connect to the repmgr database with a normal connection to query metadata. The replication connection permission is for PostgreSQL's streaming replication (and doesn't necessarily need to be the repmgr user). Cloning a standby is a one-time action; the role of the server being cloned from could change, so fixing it in the configuration file would create confusion. If &repmgr; needs to establish a connection to the primary server, it can retrieve this from the repmgr.nodes table or if necessary scan the replication cluster until it locates the active primary. Under some circumstances event notifications can be generated for servers which have not yet been registered; it's also useful to retain a record of events which includes servers removed from the replication cluster which no longer have an entry in the repmrg.nodes table. In `repmgr.conf`, set its priority to a value of 0 or less; apply the changed setting with repmgr standby register --force. Additionally, if failover is set to manual, the node will never be considered as a promotion candidate. repmgrd can monitor delayed standbys - those set up with recovery_min_apply_delay set to a non-zero value in recovery.conf - but as it's not currently possible to directly examine the value applied to the standby, repmgrd may not be able to properly evaluate the node as a promotion candidate. We recommend that delayed standbys are explicitly excluded from promotion by setting priority to 0 in repmgr.conf. Note that after registering a delayed standby, repmgrd will only start once the metadata added in the primary node has been replicated. Configure your system's logrotate service to do this; see . Check you registered the standby after recloning. If unregistered, the standby cannot be considered as a promotion candidate even if failover is set to automatic, which is probably not what you want. repmgrd will start if failover is set to manual so the node's replication status can still be monitored, if desired.