mirror of
https://github.com/EnterpriseDB/repmgr.git
synced 2026-03-24 07:36:30 +00:00
197 lines
6.2 KiB
Plaintext
197 lines
6.2 KiB
Plaintext
<refentry id="repmgr-standby-switchover">
|
|
<indexterm>
|
|
<primary>repmgr standby switchover</primary>
|
|
</indexterm>
|
|
|
|
<refmeta>
|
|
<refentrytitle>repmgr standby switchover</refentrytitle>
|
|
</refmeta>
|
|
|
|
<refnamediv>
|
|
<refname>repmgr standby switchover</refname>
|
|
<refpurpose>promote a standby to primary and demote the existing primary to a standby</refpurpose>
|
|
</refnamediv>
|
|
|
|
<refsect1>
|
|
<title>Description</title>
|
|
|
|
<para>
|
|
Promotes a standby to primary and demotes the existing primary to a standby.
|
|
This command must be run on the standby to be promoted, and requires a
|
|
passwordless SSH connection to the current primary.
|
|
</para>
|
|
<para>
|
|
If other standbys are connected to the demotion candidate, &repmgr; can instruct
|
|
these to follow the new primary if the option <literal>--siblings-follow</literal>
|
|
is specified. This requires a passwordless SSH connection between the promotion
|
|
candidate (new primary) and the standbys attached to the demotion candidate
|
|
(existing primary).
|
|
</para>
|
|
<note>
|
|
<para>
|
|
Performing a switchover is a non-trivial operation. In particular it
|
|
relies on the current primary being able to shut down cleanly and quickly.
|
|
&repmgr; will attempt to check for potential issues but cannot guarantee
|
|
a successful switchover.
|
|
</para>
|
|
</note>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>Options</title>
|
|
<variablelist>
|
|
|
|
<varlistentry>
|
|
<term><option>--always-promote</option></term>
|
|
<listitem>
|
|
<para>
|
|
Promote standby to primary, even if it is behind original primary
|
|
(original primary will be shut down in any case).
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--dry-run</option></term>
|
|
<listitem>
|
|
<para>
|
|
Check prerequisites but don't actually execute a switchover.
|
|
</para>
|
|
<important>
|
|
<para>
|
|
Success of <option>--dry-run</option> does not imply the switchover will
|
|
complete successfully, only that
|
|
the prerequisites for performing the operation are met.
|
|
</para>
|
|
</important>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>-F</option></term>
|
|
<term><option>--force</option></term>
|
|
<listitem>
|
|
<para>
|
|
Ignore warnings and continue anyway.
|
|
</para>
|
|
<para>
|
|
Specifically, if a problem is encountered when shutting down the current primary,
|
|
using <option>-F/--force</option> will cause &repmgr; to continue by promoting
|
|
the standby to be the new primary, and if <option>--siblings-follow</option> is
|
|
specified, attach any other standbys to the new primary.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--force-rewind</option></term>
|
|
<listitem>
|
|
<para>
|
|
Use <application>pg_rewind</application> to reintegrate the old primary if necessary
|
|
(PostgreSQL 9.5 and later).
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>-R</option></term>
|
|
<term><option>--remote-user</option></term>
|
|
<listitem>
|
|
<para>
|
|
System username for remote SSH operations (defaults to local system user).
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--siblings-follow</option></term>
|
|
<listitem>
|
|
<para>
|
|
Have standbys attached to the old primary follow the new primary.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>Execution</title>
|
|
|
|
<para>
|
|
Execute with the <literal>--dry-run</literal> option to test the switchover as far as
|
|
possible without actually changing the status of either node.
|
|
</para>
|
|
<para>
|
|
<application>repmgrd</application> should not be active on any nodes while a switchover is being
|
|
executed. This restriction may be lifted in a later version.
|
|
</para>
|
|
<para>
|
|
External database connections, e.g. from an application, should not be permitted while
|
|
the switchover is taking place. In particular, active transactions on the primary
|
|
can potentially disrupt the shutdown process.
|
|
</para>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>Event notifications</title>
|
|
<para>
|
|
<literal>standby_switchover</literal> and <literal>standby_promote</literal>
|
|
<link linkend="event-notifications">event notifications</link> will be generated for the new primary,
|
|
and a <literal>node_rejoin</literal> event notification for the former primary (new standby).
|
|
</para>
|
|
<para>
|
|
If using an event notification script, <literal>standby_switchover</literal>
|
|
will populate the placeholder parameter <literal>%p</literal> with the node ID of
|
|
the former primary.
|
|
</para>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>Exit codes</title>
|
|
<para>
|
|
Following exit codes can be emitted by <literal>repmgr standby switchover</literal>:
|
|
</para>
|
|
<variablelist>
|
|
|
|
<varlistentry>
|
|
<term><option>SUCCESS (0)</option></term>
|
|
<listitem>
|
|
<para>
|
|
The switchover completed successfully.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>ERR_SWITCHOVER_FAIL (18)</option></term>
|
|
<listitem>
|
|
<para>
|
|
The switchover could not be executed.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>ERR_SWITCHOVER_INCOMPLETE (22)</option></term>
|
|
<listitem>
|
|
<para>
|
|
The switchover was executed but a problem was encountered.
|
|
Typically this means the former primary could not be reattached
|
|
as a standby.
|
|
</para>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
</variablelist>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>See also</title>
|
|
<para>
|
|
For more details see the section <xref linkend="performing-switchover">.
|
|
</para>
|
|
</refsect1>
|
|
|
|
</refentry>
|