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. Can I use a standby not cloned by repmgr as a repmgr node?

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

C.2.3. What does repmgr write in recovery.conf, and what options can be set there?

See section Customising recovery.conf.

C.2.4. 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.

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.

C.2.5. 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.6. 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.7. 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.8. 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.9. 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.10. 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.11. 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.