| repmgr 4.2 Documentation | |||
|---|---|---|---|
| Prev | Up | Chapter 13. repmgrd configuration | Next |
To use repmgrd, its associated function library must be included via postgresql.conf with:
shared_preload_libraries = 'repmgr'
Changing this setting requires a restart of PostgreSQL; for more details see the PostgreSQL documentation.
If using automatic failover, the following repmgrd options *must* be set in repmgr.conf :
failover=automatic
promote_command='/usr/bin/repmgr standby promote -f /etc/repmgr.conf --log-to-file'
follow_command='/usr/bin/repmgr standby follow -f /etc/repmgr.conf --log-to-file --upstream-node-id=%n'
Adjust file paths as appropriate; alway specify the full path to the repmgr binary.
Note: repmgr will not apply pg_bindir when executing promote_command or follow_command; these can be user-defined scripts so must always be specified with the full path.
Note that the --log-to-file option will cause output generated by the repmgr command, when executed by repmgrd, to be logged to the same destination configured to receive log output for repmgrd. See repmgr.conf.sample for further repmgrd-specific settings.
When failover is set to automatic, upon detecting failure of the current primary, repmgrd will execute one of:
Note: These commands can be any valid shell script which results in one of these two actions happening, but if repmgr's standby follow or standby promote commands are not executed (either directly as shown here, or from a script which performs other actions), the repmgr metadata will not be updated and repmgr will no longer function reliably.
The follow_command should provide the --upstream-node-id=%n option to repmgr standby follow; the %n will be replaced by repmgrd with the ID of the new primary node. If this is not provided, repmgr will attempt to determine the new primary by itself, but if the original primary comes back online after the new primary is promoted, there is a risk that repmgr standby follow will result in the node continuing to follow the original primary.
If using automatic failover, currently repmgrd will need to execute repmgr standby follow to restart PostgreSQL on standbys to have them follow a new primary.
To ensure this happens smoothly, it's essential to provide the appropriate system/service restart command appropriate to your operating system via service_restart_command in repmgr.conf. If you don't do this, repmgrd will default to using pg_ctl, which can result in unexpected problems, particularly on systemd-based systems.
For more details, see service command settings.
To enable monitoring, set:
monitoring_history=yes
in repmgr.conf.
The default monitoring interval is 2 seconds; this value can be explicitly set using:
monitor_interval_secs=<seconds>
in repmgr.conf.
For more details on monitoring, see Monitoring with repmgrd.
To apply configuration file changes to a running repmgrd daemon, execute the operating system's repmgrd service reload command (see Package details for examples), or for instances which were manually started, execute kill -HUP, e.g. kill -HUP `cat /tmp/repmgrd.pid`.
Tip: Check the repmgrd log to see what changes were applied, or if any issues were encountered when reloading the configuration.
Note that only the following subset of configuration file parameters can be changed on a running repmgrd daemon:
The following set of configuration file parameters must be updated via repmgr standby register --force, as they require changes to the repmgr.nodes table so they are visible to all nodes in the replication cluster:
Note: After executing repmgr standby register --force, repmgrd must be restarted for the changes to take effect.