mirror of
https://github.com/EnterpriseDB/repmgr.git
synced 2026-03-26 16:46:28 +00:00
doc: improve BDR failover documentation
This commit is contained in:
@@ -174,17 +174,13 @@
|
|||||||
<para>
|
<para>
|
||||||
Key to "failover" execution is the <literal>event_notification_command</literal>,
|
Key to "failover" execution is the <literal>event_notification_command</literal>,
|
||||||
which is a user-definable script specified in <filename>repmpgr.conf</filename>
|
which is a user-definable script specified in <filename>repmpgr.conf</filename>
|
||||||
and which should reconfigure the proxy server/ connection pooler to point
|
and which can use a &repmgr; <link linkend="event-notifications">event notification</link>
|
||||||
to the other, still-active node.
|
to reconfigure the proxy server / connection pooler so it points to the other, still-active node.
|
||||||
|
Details of the event will be passed as parameters to the script.
|
||||||
</para>
|
</para>
|
||||||
<para>
|
<para>
|
||||||
Each time &repmgr; (or <application>repmgrd</application>) records an event,
|
Following parameter placeholders are available for the script definition in <filename>repmpgr.conf</filename>;
|
||||||
it can optionally execute the script defined in
|
these will be replaced with the appropriate value when the script is executed:
|
||||||
<literal>event_notification_command</literal> to take further action;
|
|
||||||
details of the event will be passed as parameters.
|
|
||||||
</para>
|
|
||||||
<para>
|
|
||||||
Following placeholders are available to the script:
|
|
||||||
</para>
|
</para>
|
||||||
|
|
||||||
<variablelist>
|
<variablelist>
|
||||||
@@ -231,20 +227,35 @@
|
|||||||
</para>
|
</para>
|
||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
|
<term><option>%c</option></term>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
conninfo string of the next available node (<varname>bdr_failover</varname>)
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
<varlistentry>
|
||||||
|
<term><option>%a</option></term>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
name of the next available node (<varname>bdr_failover</varname>)
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
</variablelist>
|
</variablelist>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
Note that <literal>%c</literal> and <literal>%a</literal> will only be provided during
|
Note that <literal>%c</literal> and <literal>%a</literal> are only provided with
|
||||||
<varname>bdr_failover</varname> events, which is what is of interest here.
|
particular failover events, in this case <varname>bdr_failover</varname>.
|
||||||
</para>
|
</para>
|
||||||
<para>
|
<para>
|
||||||
The provided sample script (`scripts/bdr-pgbouncer.sh`) is configured like
|
The provided sample script (`scripts/bdr-pgbouncer.sh`) is configured as follows:
|
||||||
this:
|
|
||||||
<programlisting>
|
<programlisting>
|
||||||
event_notification_command='/path/to/bdr-pgbouncer.sh %n %e %s "%c" "%a"'</programlisting>
|
event_notification_command='/path/to/bdr-pgbouncer.sh %n %e %s "%c" "%a"'</programlisting>
|
||||||
</para>
|
</para>
|
||||||
<para>
|
<para>
|
||||||
and parses the configures parameters like this:
|
and parses the placeholder parameters like this:
|
||||||
<programlisting>
|
<programlisting>
|
||||||
NODE_ID=$1
|
NODE_ID=$1
|
||||||
EVENT_TYPE=$2
|
EVENT_TYPE=$2
|
||||||
@@ -252,12 +263,14 @@
|
|||||||
NEXT_CONNINFO=$4
|
NEXT_CONNINFO=$4
|
||||||
NEXT_NODE_NAME=$5</programlisting>
|
NEXT_NODE_NAME=$5</programlisting>
|
||||||
</para>
|
</para>
|
||||||
<para>
|
<note>
|
||||||
The script also contains some hard-coded values about the <application>PgBouncer</application>
|
<para>
|
||||||
configuration for both nodes; these will need to be adjusted for your local environment
|
The sample script also contains some hard-coded values for the <application>PgBouncer</application>
|
||||||
(ideally the scripts would be maintained as templates and generated by some
|
configuration for both nodes; these will need to be adjusted for your local environment
|
||||||
kind of provisioning system).
|
(ideally the scripts would be maintained as templates and generated by some
|
||||||
</para>
|
kind of provisioning system).
|
||||||
|
</para>
|
||||||
|
</note>
|
||||||
|
|
||||||
<para>
|
<para>
|
||||||
The script performs following steps:
|
The script performs following steps:
|
||||||
|
|||||||
Reference in New Issue
Block a user