mirror of
https://github.com/EnterpriseDB/repmgr.git
synced 2026-03-22 22:56:29 +00:00
87 lines
3.8 KiB
Plaintext
87 lines
3.8 KiB
Plaintext
<refentry id="repmgr-standby-register" xreflabel="repmgr standby register">
|
|
<indexterm>
|
|
<primary>repmgr standby register</primary>
|
|
</indexterm>
|
|
|
|
<refmeta>
|
|
<refentrytitle>repmgr standby register</refentrytitle>
|
|
</refmeta>
|
|
|
|
<refnamediv>
|
|
<refname>repmgr standby register</refname>
|
|
<refpurpose>add a standby's information to the &repmgr; metadata</refpurpose>
|
|
</refnamediv>
|
|
|
|
<refsect1>
|
|
<title>Description</title>
|
|
<para>
|
|
<command>repmgr standby register</command> adds a standby's information to
|
|
the &repmgr; metadata. This command needs to be executed to enable
|
|
promote/follow operations and to allow <application>repmgrd</application> to work with the node.
|
|
An existing standby can be registered using this command. Execute with the
|
|
<literal>--dry-run</literal> option to check what would happen without actually registering the
|
|
standby.
|
|
</para>
|
|
|
|
<note>
|
|
<para>
|
|
If providing the configuration file location with <literal>-f/--config-file</literal>,
|
|
avoid using a relative path, as &repmgr; stores the configuration file location
|
|
in the repmgr metadata for use when &repmgr; is executed remotely (e.g. during
|
|
<xref linkend="repmgr-standby-switchover">). &repmgr; will attempt to convert the
|
|
a relative path into an absolute one, but this may not be the same as the path you
|
|
would explicitly provide (e.g. <filename>./repmgr.conf</filename> might be converted
|
|
to <filename>/path/to/./repmgr.conf</filename>, whereas you'd normally write
|
|
<filename>/path/to/repmgr.conf</filename>).
|
|
</para>
|
|
</note>
|
|
</refsect1>
|
|
|
|
<refsect1 id="repmgr-standby-register-wait" xreflabel="repmgr standby register --wait">
|
|
<title>Waiting for the registration to propagate to the standby</title>
|
|
<para>
|
|
Depending on your environment and workload, it may take some time for
|
|
the standby's node record to propagate from the primary to the standby. Some
|
|
actions (such as starting <application>repmgrd</application>) require that the standby's node record
|
|
is present and up-to-date to function correctly.
|
|
</para>
|
|
<para>
|
|
By providing the option <literal>--wait-sync</literal> to the
|
|
<command>repmgr standby register</command> command, &repmgr; will wait
|
|
until the record is synchronised before exiting. An optional timeout (in
|
|
seconds) can be added to this option (e.g. <literal>--wait-sync=60</literal>).
|
|
</para>
|
|
</refsect1>
|
|
|
|
<refsect1 id="repmgr-standby-register-inactive-node" xreflabel="Registering an inactive node">
|
|
<title>Registering an inactive node</title>
|
|
<para>
|
|
Under some circumstances you may wish to register a standby which is not
|
|
yet running; this can be the case when using provisioning tools to create
|
|
a complex replication cluster. In this case, by using the <literal>-F/--force</literal>
|
|
option and providing the connection parameters to the primary server,
|
|
the standby can be registered.
|
|
</para>
|
|
<para>
|
|
Similarly, with cascading replication it may be necessary to register
|
|
a standby whose upstream node has not yet been registered - in this case,
|
|
using <literal>-F/--force</literal> will result in the creation of an inactive placeholder
|
|
record for the upstream node, which will however later need to be registered
|
|
with the <literal>-F/--force</literal> option too.
|
|
</para>
|
|
<para>
|
|
When used with <command>repmgr standby register</command>, care should be taken that use of the
|
|
<literal>-F/--force</literal> option does not result in an incorrectly configured cluster.
|
|
</para>
|
|
</refsect1>
|
|
|
|
|
|
<refsect1>
|
|
<title>Event notifications</title>
|
|
<para>
|
|
A <literal>standby_register</literal> event notification will be generated.
|
|
</para>
|
|
</refsect1>
|
|
|
|
</refentry>
|