github/repmgr
1
0
Fork 0
mirror of https://github.com/EnterpriseDB/repmgr.git synced 2026-03-24 07:36:30 +00:00
Code Issues Packages Projects Releases 1 Wiki Activity

"standby follow": simplify check when follow target has higher timeline

Browse Source 
No need for a CHECKPOINT here, which simplifies things considerably.
This commit is contained in:
Ian Barwick
2019-01-11 16:34:04 +09:00
parent b3c2831bd3
commit 028c874f81
2 changed files with 35 additions and 60 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -22,6 +22,17 @@
default location; no additional arguments are required.
</para>
<para>
By default &repmgr; will attempt to attach the standby to the current primary.
If <option>--upstream-node-id</option> is provided, &repmgr; will attempt
to attach the standby to the specified node, which can be another standby.
</para>
<para>
This command will force a restart of the standby server, which must be
running.
</para>
<tip>
<para>
To re-add an inactive node to the replication cluster, use
@@ -29,29 +40,25 @@
</para>
</tip>
<para>
This command will force a restart of the standby server, which must be
running. Additionally, in order to be able to verify whether the standby
can attach to the upstream node, a <command>CHECKPOINT</command> will
be executed - this requires superuser privileges, and will be executed
even with the <option>--dry-run</option> option.
</para>
<important>
<para>
If the &repmgr; database user is not a superuser, it will not be possible
to execute <command>CHECKPOINT</command>, meaning &repmgr; may not be
able to determine whether the upstream node can be followed.
</para>
</important>
<para>
<command>repmgr standby follow</command> will wait up to
<varname>standby_follow_timeout</varname> seconds (default: <literal>30</literal>)
to verify the standby has actually connected to the new primary.
to verify the standby has actually connected to the new upstream node.
</para>
<note>
<para>
If <option>recovery_min_apply_delay</option> is set for the standby, it
will not attach to the new upstream node until it has replayed available
WAL.
</para>
<para>
Conversely, if the standby is attached follows another standby
with <option>recovery_min_apply_delay</option> set, that standby's replay
state may actually be behind that of its new downstream node.
</para>
</note>
</refsect1>
<refsect1>