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 PostgreSQL documentation section
systemd RemoveIPC
and also 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.