diff --git a/doc/repmgrd-configuration.sgml b/doc/repmgrd-configuration.sgml
index d4377bd1..35e6c62a 100644
--- a/doc/repmgrd-configuration.sgml
+++ b/doc/repmgrd-configuration.sgml
@@ -33,26 +33,32 @@
When failover is set to automatic, upon detecting failure
- of the current primary, repmgrd will execute one of
- promote_command or follow_command,
- depending on whether the current server is to become the new primary, or
- needs to follow another server which has become the new primary. Note that
- 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.
+ of the current primary, repmgrd will execute either
+ promote_command (if the current server is to become the new primary) or
+ follow_command (if the current serverneeds to follow another server which has
+ become the new primary.
+
+
+ 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.
+ 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.
+
repmgrd connection settings
@@ -76,6 +82,82 @@
PostgreSQL documentation.
+
+
+
+
+ service commands
+ repmgrd
+
+
+ repmgrd and service commands
+
+ By default, &repmgr; will use pg_ctl to
+ stop, start, restart, reloadthe PostgreSQL cluster.
+ However, if installed from a package, particularly under
+ pg_ctl, it's advisable to specify
+ the appropriate service commands to perform these options.
+
+
+ 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
+
+
+
+
+ It's also possible to specify a service_promote_command;
+ this overrides any value contained in the setting promote_command.
+ This is intended for systems which provide a package-level promote command,
+ such as Debian's pg_ctlcluster.
+
+
+
+
+ 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'
+ 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
+
+
+
+
+ If using systemd, ensure you have RemoteIPC set to off.
+ See the systemd
+ entry in the PostgreSQL wiki for details.
+
+
+
+
+
repmgrd log rotation
diff --git a/doc/switchover.sgml b/doc/switchover.sgml
index 00e3d54a..02f926b7 100644
--- a/doc/switchover.sgml
+++ b/doc/switchover.sgml
@@ -76,11 +76,12 @@
Double-check which commands will be used to stop/start/restart the current
- primary; on the primary execute:
+ primary; on the current primary execute:
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
+