mirror of
https://github.com/EnterpriseDB/repmgr.git
synced 2026-03-22 22:56:29 +00:00
doc: update documentation of "promote_command" and "service_promote_command"
The documentation implied it would override "promote_command", which is not the case. "promote_command" is used by repmgrd to execute "repmgr standby promote" (either directly or via a custom script). "service_promote_command" can be set to specify a package-level service command to promote the local PostgreSQL instance from standby to primary, e.g. Debian's pg_ctlcluster. If set, this will be executed by "repmgr standby promote". Also update code comments to clarify usage. Related to GitHub #473.
This commit is contained in:
Ian Barwick
@@ -50,10 +50,18 @@
|
||||
|
||||
<note>
|
||||
<para>
|
||||
It's also possible to specify a <varname>service_promote_command</varname>;
|
||||
this overrides any value contained in the setting <varname>promote_command</varname>.
|
||||
It's also possible to specify a <varname>service_promote_command</varname>.
|
||||
This is intended for systems which provide a package-level promote command,
|
||||
such as Debian's <application>pg_ctlcluster</application>.
|
||||
such as Debian's <application>pg_ctlcluster</application>, to promote the
|
||||
PostgreSQL from standby to primary.
|
||||
</para>
|
||||
<para>
|
||||
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.
|
||||
</para>
|
||||
<para>
|
||||
Do not confuse this with <varname>promote_command</varname>, which is used
|
||||
by <application>repmgrd</application> to execute <xref linkend="repmgr-standby-promote">.
|
||||
</para>
|
||||
</note>
|
||||
|
||||
|
||||
@@ -34,6 +34,25 @@
|
||||
the <ulink url="https://www.postgresql.org/docs/current/static/runtime-config-client.html#GUC-SHARED-PRELOAD-LIBRARIES">PostgreSQL documentation</ulink>.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
To apply configuration file changes to a running <application>repmgrd</application>
|
||||
daemon, execute the operating system's r<application>repmgrd</application> service reload command
|
||||
(see <xref linkend="appendix-packages"> for examples),
|
||||
or for instances which were manually started, execute <command>kill -HUP</command>, e.g.
|
||||
<command>kill -HUP `cat /tmp/repmgrd.pid`</command>.
|
||||
</para>
|
||||
<note>
|
||||
<para>
|
||||
Check the <application>repmgrd</application> log to see what changes were
|
||||
applied, or if any issues were encountered when reloading the configuration.
|
||||
</para>
|
||||
</note>
|
||||
<para>
|
||||
Note that only a subset of configuration file parameters can be changed on a
|
||||
running <application>repmgrd</application> daemon.
|
||||
</para>
|
||||
|
||||
|
||||
<sect2 id="repmgrd-automatic-failover-configuration">
|
||||
<title>automatic failover configuration</title>
|
||||
<para>
|
||||
@@ -162,13 +181,6 @@
|
||||
repmgrd -f /etc/repmgr.conf --pid-file /tmp/repmgrd.pid</programlisting>
|
||||
and stopped with <command>kill `cat /tmp/repmgrd.pid`</command>. Adjust paths as appropriate.
|
||||
</para>
|
||||
<para>
|
||||
To apply configuration file changes to a running <application>repmgrd</application>
|
||||
daemon, execute the operating system's service reload command (for manually started
|
||||
instances, execute <command>kill -HUP `cat /tmp/repmgrd.pid`</command>).
|
||||
Note that only a subset of configuration file parameters can be changed on a
|
||||
running <application>repmgrd</application> daemon.
|
||||
</para>
|
||||
|
||||
<sect2 id="repmgrd-pid-file" xreflabel="repmgrd's PID file">
|
||||
<indexterm>
|
||||
|
||||
@@ -280,11 +280,11 @@ ssh_options='-q -o ConnectTimeout=10' # Options to append to "ssh"
|
||||
# primary (or other upstream node)
|
||||
#reconnect_interval=10 # Interval between attempts to reconnect to an unreachable
|
||||
# primary (or other upstream node)
|
||||
#promote_command= # command to execute when promoting a new primary; use something like:
|
||||
#promote_command= # command repmgrd executes when promoting a new primary; use something like:
|
||||
#
|
||||
# repmgr standby promote -f /etc/repmgr.conf
|
||||
#
|
||||
#follow_command= # command to execute when instructing a standby to follow a new primary;
|
||||
#follow_command= # command repmgrd executes when instructing a standby to follow a new primary;
|
||||
# use something like:
|
||||
#
|
||||
# repmgr standby follow -f /etc/repmgr.conf -W --upstream-node-id=%n
|
||||
@@ -338,11 +338,11 @@ ssh_options='-q -o ConnectTimeout=10' # Options to append to "ssh"
|
||||
#service_stop_command = ''
|
||||
#service_restart_command = ''
|
||||
#service_reload_command = ''
|
||||
#service_promote_command = '' # Note: 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"
|
||||
|
||||
#service_promote_command = '' # This parameter is intended for systems which provide a
|
||||
# package-level promote command, such as Debian's
|
||||
# "pg_ctlcluster". *IMPORTANT*: it is *not* a substitute
|
||||
# for "promote_command"; do not use "repmgr standby promote"
|
||||
# (or a script which executes "repmgr standby promote") here.
|
||||
|
||||
#------------------------------------------------------------------------------
|
||||
# Status check thresholds
|
||||
|
||||
@@ -162,8 +162,8 @@ do_physical_node_check(void)
|
||||
if (config_file_options.failover == FAILOVER_AUTOMATIC)
|
||||
{
|
||||
/*
|
||||
* check that promote/follow commands are defined, otherwise repmgrd
|
||||
* won't be able to perform any useful action
|
||||
* Check that "promote_command" and "follow_command" are defined, otherwise repmgrd
|
||||
* won't be able to perform any useful action in a failover situation.
|
||||
*/
|
||||
|
||||
bool required_param_missing = false;
|
||||
@@ -175,14 +175,24 @@ do_physical_node_check(void)
|
||||
if (config_file_options.service_promote_command[0] != '\0')
|
||||
{
|
||||
/*
|
||||
* if repmgrd executes "service_promote_command" directly,
|
||||
* repmgr metadata won't get updated
|
||||
* "service_promote_command" is *not* a substitute for "promote_command";
|
||||
* it is intended for use in those systems (e.g. Debian) where there's a service
|
||||
* level promote command (e.g. pg_ctlcluster).
|
||||
*
|
||||
* "promote_command" should either execute "repmgr standby promote" directly, or
|
||||
* a script which executes "repmgr standby promote". This is essential, as the
|
||||
* repmgr metadata is updated by "repmgr standby promote".
|
||||
*
|
||||
* "service_promote_command", if set, will be executed by "repmgr standby promote",
|
||||
* but never by repmgrd.
|
||||
*
|
||||
*/
|
||||
log_hint(_("\"service_promote_command\" is set, but can only be executed by \"repmgr standby promote\""));
|
||||
}
|
||||
|
||||
required_param_missing = true;
|
||||
}
|
||||
|
||||
if (config_file_options.follow_command[0] == '\0')
|
||||
{
|
||||
log_error(_("\"follow_command\" must be defined in the configuration file"));
|
||||
@@ -2063,7 +2073,7 @@ promote_self(void)
|
||||
return FAILOVER_STATE_PROMOTION_FAILED;
|
||||
}
|
||||
|
||||
/* the presence of either of this command has been established already */
|
||||
/* the presence of this command has been established already */
|
||||
promote_command = config_file_options.promote_command;
|
||||
|
||||
log_debug("promote command is:\n \"%s\"",
|
||||
|
||||
Reference in New Issue
Block a user