github/repmgr
1
0
Fork 0
mirror of https://github.com/EnterpriseDB/repmgr.git synced 2026-03-26 16:46:28 +00:00
Code Issues Packages Projects Releases 1 Wiki Activity

doc: update "repmgr standby follow" documentation

Browse Source 
Note corner case where repmgr will not be able to check for timeline
divergence.
This commit is contained in:
Ian Barwick
2019-01-14 13:53:52 +09:00
parent d4e993a240
commit 75379eab2e
1 changed files with 28 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files

38
doc/repmgr-standby-follow.sgml
View File

@@ -16,7 +16,12 @@
<title>Description</title> <title>Description</title>
<para> <para>
Attaches the standby to a new upstream node. This command requires a valid Attaches the standby (&quot;follow candidate&quot;) to a new upstream node
(&quot;follow target&quot;). Typically this will be the primary, but this
command can also be used to attach the standby to another standby.
</para>
<para>
This command requires a valid
<filename>repmgr.conf</filename> file for the standby, either specified <filename>repmgr.conf</filename> file for the standby, either specified
explicitly with <literal>-f/--config-file</literal> or located in a explicitly with <literal>-f/--config-file</literal> or located in a
default location; no additional arguments are required. default location; no additional arguments are required.
@@ -85,14 +90,23 @@
<term><option>--dry-run</option></term> <term><option>--dry-run</option></term>
<listitem> <listitem>
<para> <para>
Check prerequisites but don't actually follow a new standby. Check prerequisites but don't actually follow a new upstream node.
</para>
<para>
This will also verify whether the standby is capable of following the new upstream node.
</para> </para>
<important> <important>
<para> <para>
This does not guarantee the standby can follow the primary; in If a standby was turned into a primary by removing <filename>recovery.conf</filename>
particular, whether the primary and standby timelines have diverged, (<application>PostgreSQL 12</application> and later: <filename>standby.signal</filename>),
can currently only be determined by actually attempting to &repmgr; will <emphasis>not</emphasis> be able to determine whether that primary's timeline
attach the standby to the primary. has diverged from the timeline of the standby (&quot;follow candidate&quot;).
</para>
<para>
We recommend always to use <link linkend="repmgr-standby-promote"><command>repmgr standby promote</command></link>
to promote a standby to primary, as this will ensure that the new primary
will perform a timeline switch (making it practical to check for timeline divergence)
and also that &repmgr; metadata is updated correctly.
</para> </para>
</important> </important>
</listitem> </listitem>
@@ -102,12 +116,16 @@
<term><option>--upstream-node-id</option></term> <term><option>--upstream-node-id</option></term>
<listitem> <listitem>
<para> <para>
Node ID of the new primary. Node ID of the new upstream node (&quot;follow target&quot;).
</para> </para>
<para> <para>
This option is intended for use by <application>repmgrd</application>, when If not provided, &repmgr; will attempt to follow the current primary node.
instructing standbys to follow the new primary. For more details </para>
see <link linkend="repmgrd-automatic-failover-configuration">Automatic failover configuration</link>. <para>
Note that when using <application>repmgrd</application>, <option>--upstream-node-id</option>
should always be configured;
see <link linkend="repmgrd-automatic-failover-configuration">Automatic failover configuration</link>
for details.
</para> </para>
</listitem> </listitem>
</varlistentry> </varlistentry>