C.2. repmgr

C.2.1. Can I register an existing PostgreSQL server with repmgr?

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.

C.2.2. How can a failed primary be re-added as a standby?

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 repmgr node rejoin documentation for details.

If pg_rewind cannot be used, then the data directory will have to be re-cloned from scratch.

C.2.3. Is there an easy way to check my primary server is correctly configured for use with repmgr?

Execute repmgr standby clone with the --dry-run option; this will report any configuration problems which need to be rectified.

C.2.4. When cloning a standby, how can I get repmgr to copy postgresql.conf and pg_hba.conf from the PostgreSQL configuration directory in /etc?

Use the command line option --copy-external-config-files. For more details see Copying configuration files.

C.2.5. Do I need to include shared_preload_libraries = 'repmgr' in postgresql.conf if I'm not using repmgrd?

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.

C.2.6. I've provided replication permission for the repmgr user in pg_hba.conf but repmgr/repmgrd complains it can't connect to the server... Why?

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).

C.2.7. When cloning a standby, why do I need to provide the connection parameters for the primary server on the command line, not in the configuration file?

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.

C.2.8. When cloning a standby, how do I ensure the WAL files are placed in a custom directory?

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.

C.2.9. Why is there no foreign key on the node_id column in the repmgr.events table?

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.