mirror of
https://github.com/EnterpriseDB/repmgr.git
synced 2026-03-27 17:06:29 +00:00
doc: expand repmgrd configuration section
This commit is contained in:
Ian Barwick
@@ -36,19 +36,91 @@
|
|||||||
|
|
||||||
|
|
||||||
<sect2 id="repmgrd-automatic-failover-configuration">
|
<sect2 id="repmgrd-automatic-failover-configuration">
|
||||||
<title>Automatic failover configuration</title>
|
<title>Required configuration for automatic failover</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
If using automatic failover, the following <application>repmgrd</application> options *must* be set in
|
The following <application>repmgrd</application> options <emphasis>must</emphasis> be set in
|
||||||
<filename>repmgr.conf</filename> :
|
<filename>repmgr.conf</filename>:
|
||||||
|
|
||||||
|
<itemizedlist spacing="compact" mark="bullet">
|
||||||
|
<listitem>
|
||||||
|
<simpara><option>failover</option></simpara>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<simpara><option>promote_command</option></simpara>
|
||||||
|
</listitem>
|
||||||
|
<listitem>
|
||||||
|
<simpara><option>follow_command</option></simpara>
|
||||||
|
</listitem>
|
||||||
|
</itemizedlist>
|
||||||
|
</para>
|
||||||
|
|
||||||
|
|
||||||
|
<para>
|
||||||
|
Example:
|
||||||
<programlisting>
|
<programlisting>
|
||||||
failover=automatic
|
failover=automatic
|
||||||
promote_command='/usr/bin/repmgr standby promote -f /etc/repmgr.conf --log-to-file'
|
promote_command='/usr/bin/repmgr standby promote -f /etc/repmgr.conf --log-to-file'
|
||||||
follow_command='/usr/bin/repmgr standby follow -f /etc/repmgr.conf --log-to-file --upstream-node-id=%n'</programlisting>
|
follow_command='/usr/bin/repmgr standby follow -f /etc/repmgr.conf --log-to-file --upstream-node-id=%n'</programlisting>
|
||||||
</para>
|
</para>
|
||||||
<para>
|
<para>
|
||||||
Adjust file paths as appropriate; alway specify the full path to the &repmgr; binary.
|
Details of each option are as follows:
|
||||||
|
</para>
|
||||||
|
<variablelist>
|
||||||
|
<varlistentry>
|
||||||
|
|
||||||
|
<indexterm>
|
||||||
|
<primary>failover</primary>
|
||||||
|
</indexterm>
|
||||||
|
<term><option>failover</option></term>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
<option>failover</option> can be one of <literal>automatic</literal> or <literal>manual</literal>.
|
||||||
|
</para>
|
||||||
|
<note>
|
||||||
|
<para>
|
||||||
|
If <option>failover</option> is set to <literal>manual</literal>, <application>repmgrd</application>
|
||||||
|
will not take any action if a failover situation is detected, and the node may need to
|
||||||
|
be modified manually (e.g. by executing <command><link linkend="repmgr-standby-follow">repmgr standby follow</link></command>).
|
||||||
|
</para>
|
||||||
|
</note>
|
||||||
|
|
||||||
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
|
||||||
|
<varlistentry>
|
||||||
|
<indexterm>
|
||||||
|
<primary>promote_command</primary>
|
||||||
|
</indexterm>
|
||||||
|
<term><option>promote_command</option></term>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
The program or script defined in <option>promote_command</option> will be executed
|
||||||
|
in a failover situation when <application>repmgrd</application> determines that
|
||||||
|
the current node is to become the new primary node.
|
||||||
|
</para>
|
||||||
|
<para>
|
||||||
|
Normally <option>promote_command</option> is set as &repmgr;'s
|
||||||
|
<command><link linkend="repmgr-standby-promote">repmgr standby promote</link></command> command.
|
||||||
|
</para>
|
||||||
|
<para>
|
||||||
|
It is also possible to provide e.g. a shell script to e.g. perform user-defined tasks
|
||||||
|
before promoting the current node. In this case the script <emphasis>must</emphasis>
|
||||||
|
at some point execute <command><link linkend="repmgr-standby-promote">repmgr standby promote</link></command>
|
||||||
|
to promote the node; if this is not done, &repmgr; metadata will not be updated and
|
||||||
|
&repmgr; will no longer function reliably.
|
||||||
|
</para>
|
||||||
|
<para>
|
||||||
|
Example:
|
||||||
|
<programlisting>
|
||||||
|
promote_command='/usr/bin/repmgr standby promote -f /etc/repmgr.conf --log-to-file'</programlisting>
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
Note that the <literal>--log-to-file</literal> option will cause
|
||||||
|
output generated by the &repmgr; command, when executed by <application>repmgrd</application>,
|
||||||
|
to be logged to the same destination configured to receive log output for <application>repmgrd</application>.
|
||||||
|
</para>
|
||||||
<note>
|
<note>
|
||||||
<para>
|
<para>
|
||||||
&repmgr; will not apply <option>pg_bindir</option> when executing <option>promote_command</option>
|
&repmgr; will not apply <option>pg_bindir</option> when executing <option>promote_command</option>
|
||||||
@@ -56,57 +128,85 @@
|
|||||||
specified with the full path.
|
specified with the full path.
|
||||||
</para>
|
</para>
|
||||||
</note>
|
</note>
|
||||||
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
|
||||||
|
<varlistentry>
|
||||||
|
<indexterm>
|
||||||
|
<primary>follow_command</primary>
|
||||||
|
</indexterm>
|
||||||
|
<term><option>follow_command</option></term>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
The program or script defined in <option>follow_command</option> will be executed
|
||||||
|
in a failover situation when <application>repmgrd</application> determines that
|
||||||
|
the current node is to follow the new primary node.
|
||||||
|
</para>
|
||||||
|
<para>
|
||||||
|
Normally <option>follow_command</option> is set as &repmgr;'s
|
||||||
|
<command><link linkend="repmgr-standby-follow">repmgr standby promote</link></command> command.
|
||||||
|
</para>
|
||||||
|
<para>
|
||||||
|
The <option>follow_command</option> parameter
|
||||||
|
should provide the <literal>--upstream-node-id=%n</literal>
|
||||||
|
option to <command>repmgr standby follow</command>; the <literal>%n</literal> will be replaced by
|
||||||
|
<application>repmgrd</application> with the ID of the new primary node. If this is not provided,
|
||||||
|
<command>repmgr standby follow</command> 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
|
||||||
|
<command>repmgr standby follow</command> will result in the node continuing to follow
|
||||||
|
the original primary.
|
||||||
|
</para>
|
||||||
|
<para>
|
||||||
|
It is also possible to provide e.g. a shell script to e.g. perform user-defined tasks
|
||||||
|
before promoting the current node. In this case the script <emphasis>must</emphasis>
|
||||||
|
at some point execute <command><link linkend="repmgr-standby-follow">repmgr standby follow</link></command>
|
||||||
|
to promote the node; if this is not done, &repmgr; metadata will not be updated and
|
||||||
|
&repmgr; will no longer function reliably.
|
||||||
|
</para>
|
||||||
|
<para>
|
||||||
|
Example:
|
||||||
|
<programlisting>
|
||||||
|
follow_command='/usr/bin/repmgr standby follow -f /etc/repmgr.conf --log-to-file --upstream-node-id=%n'</programlisting>
|
||||||
|
</para>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Note that the <literal>--log-to-file</literal> option will cause
|
Note that the <literal>--log-to-file</literal> option will cause
|
||||||
output generated by the &repmgr; command, when executed by <application>repmgrd</application>,
|
output generated by the &repmgr; command, when executed by <application>repmgrd</application>,
|
||||||
to be logged to the same destination configured to receive log output for <application>repmgrd</application>.
|
to be logged to the same destination configured to receive log output for <application>repmgrd</application>.
|
||||||
See <filename><ulink url="https://raw.githubusercontent.com/2ndQuadrant/repmgr/master/repmgr.conf.sample">repmgr.conf.sample</ulink></filename>
|
|
||||||
for further <application>repmgrd</application>-specific settings.
|
|
||||||
</para>
|
</para>
|
||||||
<para>
|
|
||||||
When <varname>failover</varname> is set to <literal>automatic</literal>, upon detecting failure
|
|
||||||
of the current primary, <application>repmgrd</application> will execute one of:
|
|
||||||
</para>
|
|
||||||
<itemizedlist spacing="compact" mark="bullet">
|
|
||||||
<listitem>
|
|
||||||
<simpara>
|
|
||||||
<varname>promote_command</varname> (if the current server is to become the new primary)
|
|
||||||
</simpara>
|
|
||||||
</listitem>
|
|
||||||
<listitem>
|
|
||||||
<simpara>
|
|
||||||
<varname>follow_command</varname> (if the current server needs to follow another server which has
|
|
||||||
become the new primary)
|
|
||||||
</simpara>
|
|
||||||
</listitem>
|
|
||||||
</itemizedlist>
|
|
||||||
<note>
|
<note>
|
||||||
<para>
|
<para>
|
||||||
These commands can be any valid shell script which results in one of these
|
&repmgr; will not apply <option>pg_bindir</option> when executing <option>promote_command</option>
|
||||||
two actions happening, but if &repmgr;'s <command>standby follow</command> or
|
or <option>follow_command</option>; these can be user-defined scripts so must always be
|
||||||
<command>standby promote</command>
|
specified with the full path.
|
||||||
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.
|
|
||||||
</para>
|
</para>
|
||||||
</note>
|
</note>
|
||||||
|
</listitem>
|
||||||
|
|
||||||
|
</varlistentry>
|
||||||
|
|
||||||
|
</variablelist>
|
||||||
|
|
||||||
|
|
||||||
|
</sect2>
|
||||||
|
|
||||||
|
<sect2 id="repmgrd-automatic-failover-configuration-optionanl">
|
||||||
|
<title>Optional configuration for automatic failover</title>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The <varname>follow_command</varname> should provide the <literal>--upstream-node-id=%n</literal>
|
The following configuraton options can be used to fine-tune automatic failove:
|
||||||
option to <command>repmgr standby follow</command>; the <literal>%n</literal> will be replaced by
|
|
||||||
<application>repmgrd</application> 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
|
|
||||||
<command>repmgr standby follow</command> will result in the node continuing to follow
|
|
||||||
the original primary.
|
|
||||||
</para>
|
</para>
|
||||||
|
<variablelist>
|
||||||
|
|
||||||
|
<varlistentry>
|
||||||
|
|
||||||
<para>
|
|
||||||
<indexterm>
|
<indexterm>
|
||||||
<primary>connection_check_type</primary>
|
<primary>connection_check_type</primary>
|
||||||
</indexterm>
|
</indexterm>
|
||||||
Additionally, the option <option>connection_check_type</option> to enable selection of the method
|
<term><option>connection_check_type</option></term>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
The option <option>connection_check_type</option> is used to select the method
|
||||||
<application>repmgrd</application> uses to determine whether the upstream node is available.
|
<application>repmgrd</application> uses to determine whether the upstream node is available.
|
||||||
</para>
|
</para>
|
||||||
<para>
|
<para>
|
||||||
@@ -126,6 +226,15 @@
|
|||||||
</listitem>
|
</listitem>
|
||||||
</itemizedlist>
|
</itemizedlist>
|
||||||
</para>
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
|
||||||
|
</variablelist>
|
||||||
|
|
||||||
|
<para>
|
||||||
|
See <filename><ulink url="https://raw.githubusercontent.com/2ndQuadrant/repmgr/master/repmgr.conf.sample">repmgr.conf.sample</ulink></filename>
|
||||||
|
for further <application>repmgrd</application>-specific settings.
|
||||||
|
</para>
|
||||||
|
|
||||||
</sect2>
|
</sect2>
|
||||||
|
|
||||||
|
|||||||
@@ -329,6 +329,10 @@ ssh_options='-q -o ConnectTimeout=10' # Options to append to "ssh"
|
|||||||
# WAL receivers
|
# WAL receivers
|
||||||
#primary_visibility_consensus=false # If "true", only continue with failover if no standbys have seen
|
#primary_visibility_consensus=false # If "true", only continue with failover if no standbys have seen
|
||||||
# the primary node recently
|
# the primary node recently
|
||||||
|
#failover_validation_command= # Script to execute for an external mechanism to validate the failover
|
||||||
|
# decision made by repmgrd. One or both of the following parameter placeholders
|
||||||
|
# should be provided, which will be replaced by repmgrd with the appropriate
|
||||||
|
# value: %n (node_id), %a (node_name)
|
||||||
|
|
||||||
#------------------------------------------------------------------------------
|
#------------------------------------------------------------------------------
|
||||||
# service control commands
|
# service control commands
|
||||||
|
|||||||
Reference in New Issue
Block a user