mirror of
https://github.com/EnterpriseDB/repmgr.git
synced 2026-03-25 08:06:29 +00:00
64035ef701
For events generated by these commands, it may be useful to know details of the primary node. This makes following additional parameters available to event notification scripts: - %p: node ID of the primary - %a: node name of the primary - %c: conninfo string for the primary Implements GitHub #375
105 lines
3.1 KiB
Plaintext
105 lines
3.1 KiB
Plaintext
<refentry id="repmgr-standby-follow">
|
|
<indexterm>
|
|
<primary>repmgr standby follow</primary>
|
|
</indexterm>
|
|
|
|
<refmeta>
|
|
<refentrytitle>repmgr standby follow</refentrytitle>
|
|
</refmeta>
|
|
|
|
<refnamediv>
|
|
<refname>repmgr standby follow</refname>
|
|
<refpurpose>attach a standby to a new primary</refpurpose>
|
|
</refnamediv>
|
|
|
|
<refsect1>
|
|
<title>Description</title>
|
|
|
|
<para>
|
|
Attaches the standby to a new primary. This command requires a valid
|
|
<filename>repmgr.conf</filename> file for the standby, either specified
|
|
explicitly with <literal>-f/--config-file</literal> or located in a
|
|
default location; no additional arguments are required.
|
|
</para>
|
|
<para>
|
|
This command will force a restart of the standby server, which must be
|
|
running. It can only be used to attach an active standby to the current primary node
|
|
(and not to another standby).
|
|
</para>
|
|
<para>
|
|
To re-add an inactive node to the replication cluster, see
|
|
<xref linkend="repmgr-node-rejoin">
|
|
</para>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>Example</title>
|
|
<para>
|
|
<programlisting>
|
|
$ repmgr -f /etc/repmgr.conf standby follow
|
|
INFO: setting node 3's primary to node 2
|
|
NOTICE: restarting server using "pg_ctl -l /var/log/postgres/startup.log -w -D '/var/lib/postgres/data' restart"
|
|
waiting for server to shut down........ done
|
|
server stopped
|
|
waiting for server to start.... done
|
|
server started
|
|
NOTICE: STANDBY FOLLOW successful
|
|
DETAIL: node 3 is now attached to node 2</programlisting>
|
|
</para>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>Options</title>
|
|
<variablelist>
|
|
|
|
<varlistentry>
|
|
<term><option>--dry-run</option></term>
|
|
<listitem>
|
|
<para>
|
|
Check prerequisites but don't actually follow a new standby.
|
|
</para>
|
|
<important>
|
|
<para>
|
|
This does not guarantee the standby can follow the primary; in
|
|
particular, whether the primary and standby timelines have diverged,
|
|
can currently only be determined by actually attempting to
|
|
attach the standby to the primary.
|
|
</para>
|
|
</important>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>-W</option></term>
|
|
<term><option>--wait</option></term>
|
|
<listitem>
|
|
<para>
|
|
Wait for a primary to appear.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
</variablelist>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>Event notifications</title>
|
|
<para>
|
|
A <literal>standby_follow</literal> <link linkend="event-notifications">event notification</link> will be generated.
|
|
</para>
|
|
<para>
|
|
If provided, &repmgr; will subsitute the placeholders <literal>%p</literal> with the node ID of the primary
|
|
being followed, <literal>%c</literal> with its <literal>conninfo</literal> string, and
|
|
<literal>%a</literal> with its node name.
|
|
</para>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>See also</title>
|
|
<para>
|
|
<xref linkend="repmgr-node-rejoin">
|
|
</para>
|
|
</refsect1>
|
|
</refentry>
|
|
|