In some circumstances, repmgr (and repmgrd) need to
be able to stop, start or restart PostgreSQL. repmgr commands which need to do this
include repmgr standby follow,
repmgr standby switchover and
repmgr node rejoin.
By default, repmgr will use PostgreSQL's pg_ctl utility to control the PostgreSQL
server. However this can lead to various problems, particularly when PostgreSQL has been
installed from packages, and especially so if systemd is in use.
If using systemd, ensure you have RemoveIPC set to off.
See the systemd
entry in the PostgreSQL wiki for details.
With this in mind, we recommend to always configure repmgr to use the available system service commands.
To do this, specify the appropriate command for each action
in repmgr.conf using the following configuration
parameters:
service_start_command
service_stop_command
service_restart_command
service_reload_command
repmgr will not apply pg_bindir when executing any of these commands;
these can be user-defined scripts so must always be specified with the full path.
It's also possible to specify a service_promote_command.
This is intended for systems which provide a package-level promote command,
such as Debian's pg_ctlcluster, to promote the
PostgreSQL from standby to primary.
If your packaging system does not provide such a command, it can be left empty, and repmgr will generate the appropriate `pg_ctl ... promote` command.
Do not confuse this with promote_command, which is used
by repmgrd to execute repmgr standby promote.
To confirm which command repmgr will execute for each action, use
repmgr node service --list-actions --action=..., e.g.:
repmgr -f /etc/repmgr.conf node service --list-actions --action=stop
repmgr -f /etc/repmgr.conf node service --list-actions --action=start
repmgr -f /etc/repmgr.conf node service --list-actions --action=restart
repmgr -f /etc/repmgr.conf node service --list-actions --action=reload
These commands will be executed by the system user which repmgr runs as (usually postgres)
and will probably require passwordless sudo access to be able to execute the command.
For example, using systemd on CentOS 7, the service commands can be set as follows:
service_start_command = 'sudo systemctl start postgresql-9.6'
service_stop_command = 'sudo systemctl stop postgresql-9.6'
service_restart_command = 'sudo systemctl restart postgresql-9.6'
service_reload_command = 'sudo systemctl reload postgresql-9.6'
and /etc/sudoers should be set as follows:
Defaults:postgres !requiretty
postgres ALL = NOPASSWD: /usr/bin/systemctl stop postgresql-9.6, \
/usr/bin/systemctl start postgresql-9.6, \
/usr/bin/systemctl restart postgresql-9.6, \
/usr/bin/systemctl reload postgresql-9.6
Debian/Ubuntu users: instead of calling sudo systemctl directly, use
sudo pg_ctlcluster, e.g.:
service_start_command = 'sudo pg_ctlcluster 9.6 main start'
service_stop_command = 'sudo pg_ctlcluster 9.6 main stop'
service_restart_command = 'sudo pg_ctlcluster 9.6 main restart'
service_reload_command = 'sudo pg_ctlcluster 9.6 main reload'
and set /etc/sudoers accordingly.
While pg_ctlcluster will work when executed as user postgres,
it's strongly recommended to use sudo pg_ctlcluster on systemd
systems, to ensure systemd has a correct picture of
the PostgreSQL application state.