| repmgr 4.1.1 Documentation | |||
|---|---|---|---|
| Prev | Up | Chapter 4. repmgr configuration | Next |
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 to control the PostgreSQL server. However this can lead to various problems, particularly when PostgreSQL has been installed from packages, and expecially so if systemd is in use.
Note: 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
Note: 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.
Note: 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 --action=..., e.g.:
repmgr -f /etc/repmgr.conf node service --list --action=stop
repmgr -f /etc/repmgr.conf node service --list --action=start
repmgr -f /etc/repmgr.conf node service --list --action=restart
repmgr -f /etc/repmgr.conf node service --list --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
Important: 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.