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.

For a standby which has been manually cloned or recovered from an external backup manager such as Barman, the command repmgr standby clone --replication-conf-only can be used to create the correct replication configuration file for use with repmgr (and will create a replication slot if required). Once this has been done, register the node as usual.

See section Customising replication configuration.

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.

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.

Note that pg_rewind is available as part of the core PostgreSQL distribution from PostgreSQL 9.5, and as a third-party utility for PostgreSQL 9.3 and 9.4.

repmgr provides the command repmgr node rejoin which can optionally execute pg_rewind; see the repmgr node rejoin documentation for details, in particular the section Using pg_rewind.

If pg_rewind cannot be used, then the data directory will need 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 Copying configuration files.

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 and repmgrd 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 on the local node, and if necessary scan the replication cluster until it locates the active primary.

Provide the option --waldir (--xlogdir in PostgreSQL 9.6 and earlier) with the absolute path to the WAL directory in pg_basebackup_options. For more details see pg_basebackup options when cloning a standby.

In repmgr 5.2 and later, this setting will also be honoured when cloning from Barman.

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 repmgr.nodes table.

This is to ensure that user-supplied values which are written as parameter values in recovery.conf are escaped correctly and do not cause errors when the file is parsed.

The escaping is performed by an internal PostgreSQL routine, which leaves strings consisting of digits and alphabetical characters only as-is, but wraps everything else in pairs of single quotes, even if the string does not contain any characters which need escaping.

Beginning with repmgr 5.2, the metadata tables associated with the repmgr extension (repmgr.nodes, repmgr.events and repmgr.monitoring_history) have been marked as dumpable as they contain configuration and user-generated data.

To exclude these from pg_dump output, add the flag --exclude-schema=repmgr.

To exclude individual repmgr metadata tables from pg_dump output, add the flag e.g. --exclude-table=repmgr.monitoring_history. This flag can be provided multiple times to exclude individual tables,