C.3. repmgrd

C.3.1. How can I prevent a node from ever being promoted to primary?

In repmgr.conf, set its priority to a value of 0; 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.

C.3.2. Does repmgrd support delayed standbys?

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.

C.3.3. How can I get repmgrd to rotate its logfile?

Configure your system's logrotate service to do this; see Section 13.4.

C.3.4. I've recloned a failed primary as a standby, but repmgrd refuses to start?

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.

C.3.5. repmgrd ignores pg_bindir when executing promote_command or follow_command

promote_command or follow_command can be user-defined scripts, so repmgr will not apply pg_bindir even if excuting repmgr. Always provide the full path; see Section 13.1.1 for more details.

C.3.6. repmgrd aborts startup with the error "upstream node must be running before repmgrd can start"

repmgrd does this to avoid starting up on a replication cluster which is not in a healthy state. If the upstream is unavailable, repmgrd may initiate a failover immediately after starting up, which could have unintended side-effects, particularly if repmgrd is not running on other nodes.

In particular, it's possible that the node's local copy of the repmgr.nodes copy is out-of-date, which may lead to incorrect failover behaviour.

The onus is therefore on the adminstrator to manually set the cluster to a stable, healthy state before starting repmgrd.