mirror of
https://github.com/EnterpriseDB/repmgr.git
synced 2026-03-22 22:56:29 +00:00
2799 lines
99 KiB
XML
2799 lines
99 KiB
XML
<appendix id="appendix-release-notes">
|
|
<title>Release notes</title>
|
|
<indexterm>
|
|
<primary>Release notes</primary>
|
|
</indexterm>
|
|
|
|
<para>
|
|
Changes to each &repmgr; release are documented in the release notes.
|
|
Please read the release notes for all versions between
|
|
your current version and the version you are plan to upgrade to
|
|
before performing an upgrade, as there may be version-specific upgrade steps.
|
|
</para>
|
|
|
|
<para>
|
|
See also: <xref linkend="upgrading-repmgr"/>
|
|
</para>
|
|
|
|
<!-- remember to update the release date in ../repmgr_version.h.in -->
|
|
|
|
<sect1 id="release-5.2.0">
|
|
<title>Release 5.2.0</title>
|
|
<para><emphasis>??? ?? ???, 2020</emphasis></para>
|
|
|
|
<para>
|
|
&repmgr; 5.2.0 is a major release.
|
|
</para>
|
|
<para>
|
|
This release provides support for <ulink url="https://www.postgresql.org/docs/13/release-13.htmll">PostgreSQL 13</ulink>, released in September 2020.
|
|
</para>
|
|
<para>
|
|
This release removes support for PostgreSQL 9.3, which was
|
|
<ulink url="https://www.postgresql.org/docs/9.3/release-9-3-25.html">designated EOL in November 2018</ulink>.
|
|
</para>
|
|
|
|
<sect2>
|
|
<title>General improvements</title>
|
|
<para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
Configuration: support <command>include</command>, <command>include_dir</command> and
|
|
<command>include_if_exists</command> directives (see <xref linkend="configuration-file-include-directives"/>).
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<link linkend="repmgr-standby-switchover"><command>repmgr standby switchover</command></link>:
|
|
Improve sanity check failure log output from the demotion candidate.
|
|
</para>
|
|
<para>
|
|
If database connection configuration is not consistent across all nodes, it's
|
|
possible remote &repmgr; invocations (e.g. during switchover, from the promotion candidate
|
|
to the demotion candidate) will not be able to connect to the database. This will
|
|
now be explicitly reported as a database connection failure, rather than as a failure
|
|
of the respective sanity check.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<link linkend="repmgr-cluster-crosscheck">repmgr cluster crosscheck</link> /
|
|
<link linkend="repmgr-cluster-matrix">repmgr cluster matrix</link>:
|
|
improve text mode output format, in particular so that node identifiers of arbitrary length are
|
|
displayed correctly.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<link linkend="repmgr-primary-unregister">repmgr primary unregister</link>:
|
|
the <option>--force</option> can be provided to unregister an active primary node, provided
|
|
it has no registered standby nodes.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<link linkend="repmgr-standby-clone">repmgr standby clone</link>: new option
|
|
<option>--verify-backup</option> to run PostgreSQL's
|
|
<ulink url="https://www.postgresql.org/docs/13/app-pgverifybackup.html">pg_verifybackup</ulink>
|
|
utility after cloning a standby to verify the integrity of the copied data
|
|
(PostgreSQL 13 and later).
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<link linkend="repmgr-standby-clone">repmgr standby clone</link>:
|
|
when cloning from Barman, setting <option>--waldir</option>
|
|
(PostgreSQL 9.6 and earlier: <option>--xlogdir</option>) in
|
|
<option>pg_basebackup_options</option> will cause &repmgr; to create
|
|
a WAL directory outside of the main data directory and symlink
|
|
it from there, in the same way as would happen when cloning
|
|
using <application>pg_basebackup</application>.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<link linkend="repmgr-standby-follow">repmgr standby follow</link>:
|
|
In PostgreSQL 13 and later, a standby no longer requires a restart to
|
|
follow a new upstream node.
|
|
</para>
|
|
<para>
|
|
The old behaviour (always restarting the standby to follow a new node)
|
|
can be restored by setting the configuration file parameter
|
|
<varname>standby_follow_restart</varname> to <literal>true</literal>.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<link linkend="repmgr-node-rejoin">repmgr node rejoin</link>:
|
|
enable a node to attach to a target node even the target node
|
|
has a lower timeline (PostgreSQL 9.6 and later).
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<link linkend="repmgr-node-check">repmgr node check</link>:
|
|
option <option>--db-connection</option> added to check if &repmgr;
|
|
can connect to the database on the local node.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<link linkend="repmgr-node-check">repmgr node check</link>:
|
|
report database connection error if the <option>--optformat</option> was provided.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Improve handling of pg_control read errors.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
It is now possible to dump the contents of &repmgr; metadata tables with
|
|
<application>pg_dump</application>.
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</para>
|
|
</sect2>
|
|
<sect2>
|
|
<title>repmgrd enhancements</title>
|
|
<para>
|
|
<itemizedlist>
|
|
|
|
<listitem>
|
|
<para>
|
|
Following additional parameters can be provided to <varname>failover_validation_command</varname>:
|
|
<itemizedlist spacing="compact" mark="bullet">
|
|
<listitem>
|
|
<simpara><literal>%n</literal>: node ID</simpara>
|
|
</listitem>
|
|
<listitem>
|
|
<simpara><literal>%a</literal>: node name</simpara>
|
|
</listitem>
|
|
<listitem>
|
|
<simpara><literal>%v</literal>: number of visible nodes</simpara>
|
|
</listitem>
|
|
<listitem>
|
|
<simpara><literal>%u</literal>: number of shared upstream nodes</simpara>
|
|
</listitem>
|
|
<listitem>
|
|
<simpara><literal>%t</literal>: total number of nodes</simpara>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
Configuration option <varname>always_promote</varname> (default: <literal>false</literal>)
|
|
to control whether a node should be promoted if the &repmgr; metadata is not up-to-date
|
|
on that node.
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Bug fixes</title>
|
|
<para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
<link linkend="repmgr-standby-clone">repmgr standby clone</link>:
|
|
fix issue with cloning from Barman where the tablespace mapping file was
|
|
not flushed to disk before attempting to retrieve files from Barman. GitHub #650.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
<link linkend="repmgr-node-rejoin">repmgr node rejoin</link>:
|
|
ensure that when verifying a standby node has attached to its upstream, the
|
|
node has started streaming before confirming the success of the rejoin operation.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
&repmgrd;: ensure primary connection is reset if same as upstream. GitHub #633.
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</para>
|
|
</sect2>
|
|
|
|
</sect1>
|
|
|
|
<sect1 id="release-5.1.0">
|
|
<title id="release-current">Release 5.1.0</title>
|
|
<para><emphasis>Mon 13 April, 2020</emphasis></para>
|
|
|
|
<para>
|
|
&repmgr; 5.1.0 is a major release.
|
|
</para>
|
|
<para>
|
|
For details on how to upgrade an existing &repmgr; installation, see
|
|
documentation section <link linkend="upgrading-major-version">Upgrading a major version release</link>.
|
|
</para>
|
|
<para>
|
|
If &repmgrd; is in use, a PostgreSQL restart <emphasis>is</emphasis> required;
|
|
in that case we suggest combining this &repmgr; upgrade with the next PostgreSQL
|
|
minor release, which will require a PostgreSQL restart in any case.
|
|
</para>
|
|
|
|
|
|
<sect2>
|
|
<title>Compatibility changes</title>
|
|
<para>
|
|
The <link linkend="repmgr-standby-clone"><command>repmgr standby clone</command></link>
|
|
<option>--recovery-conf-only</option> option has been renamed to
|
|
<option>--replication-conf-only</option>. <option>--recovery-conf-only</option> will
|
|
still be accepted as an alias.
|
|
</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>General improvements</title>
|
|
<para>
|
|
<itemizedlist>
|
|
|
|
<listitem>
|
|
<para>
|
|
The requirement that the &repmgr; user is a database superuser has been
|
|
removed as far as possible.
|
|
</para>
|
|
<para>
|
|
In theory, &repmgr; can be operated with a normal database user for managing
|
|
the &repmgr; database, and a separate replication user for managing replication
|
|
connections (and replication slots, if these are in use).
|
|
</para>
|
|
<para>
|
|
Some operations will still require superuser permissions, e.g. for issuing
|
|
a <command>CHECKPOINT</command> as par of a switchover operation; in this case
|
|
a valid superuser should be provided with the <option>-S</option>/<option>--superuser</option>
|
|
option.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<link linkend="repmgr-standby-clone"><command>repmgr standby clone</command></link>:
|
|
Warn if neither of data page checksums or <option>wal_log_hints</option> are active,
|
|
as this will preclude later usage of <command>pg_rewind</command>.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<link linkend="repmgr-standby-promote"><command>repmgr standby promote</command></link>:
|
|
when executed with <option>--dry-run</option>, the method which would be used to promote the node
|
|
will be displayed.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<link linkend="repmgr-standby-follow"><command>repmgr standby follow</command></link>:
|
|
Improve logging and checking of potential failure situations.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<link linkend="repmgr-standby-switchover"><command>repmgr standby switchover</command></link>:
|
|
Replication configuration files (PostgreSQL 11 and earlier:
|
|
<filename>recovery.conf</filename>; PostgreSQL 12 and later: <filename>postgresql.auto.conf</filename>)
|
|
will be checked to ensure they are owned by the same user who owns the PostgreSQL
|
|
data directory.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<link linkend="repmgr-standby-switchover"><command>repmgr standby switchover</command></link>:
|
|
Provide additional information in <option>--dry-run mode</option> output.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<link linkend="repmgr-standby-switchover"><command>repmgr standby switchover</command></link>:
|
|
Checks that the demotion candidate's registered repmgr.conf file can be found, to
|
|
prevent confusing references to an incorrectly configured data directory. GitHub 615.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<link linkend="repmgr-node-check"><command>repmgr node check</command></link>:
|
|
accept option <option>-S</option>/<option>--superuser</option>. GitHub #621.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<link linkend="repmgr-node-check"><command>repmgr node check</command></link>:
|
|
add <option>--upstream</option> option to check whether the node is attached
|
|
to the expected upstream node.
|
|
</para>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Bug fixes</title>
|
|
<para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
Ensure <link linkend="repmgr-node-rejoin"><command>repmgr node rejoin</command></link>
|
|
checks for available replication slots on the rejoin target.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<link linkend="repmgr-standby-follow"><command>repmgr standby follow</command></link> and
|
|
<link linkend="repmgr-node-rejoin"><command>repmgr node rejoin</command></link> will now return
|
|
an error code if the operation fails if a replication slot is not available or cannot
|
|
be created on the follow/rejoin target.
|
|
</para>
|
|
</listitem>
|
|
|
|
|
|
<listitem>
|
|
<para>
|
|
<link linkend="repmgr-standby-promote"><command>repmgr standby promote</command></link>:
|
|
in <option>--dry-run mode</option>, display promote command which will be executed.
|
|
</para>
|
|
</listitem>
|
|
|
|
|
|
<listitem>
|
|
<para>
|
|
<link linkend="repmgr-standby-promote"><command>repmgr standby promote</command></link>
|
|
will check if the <literal>repmgr</literal> user has permission to execute
|
|
<function>pg_promote()</function> and fall back to <command>pg_ctl promote</command> if
|
|
necessary.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<link linkend="repmgr-standby-switchover"><command>repmgr standby switchover</command></link>:
|
|
check for demotion candidate reattachment as late as possible to avoid spurious failure
|
|
reports.
|
|
</para>
|
|
</listitem>
|
|
|
|
|
|
<listitem>
|
|
<para>
|
|
&repmgrd;: check for presence of <option>promote_command</option> and
|
|
<option>follow_command</option> on receipt of <literal>SIGHUP</literal>. GitHub 614.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
Fix situation where replication connections were not created correctly, which
|
|
could lead to spurious replication connection failures in some situations, e.g.
|
|
where password files are used.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
Ensure <filename>postgresql.auto.conf</filename> is created with
|
|
correct permissions (PostgreSQL 12 and later).
|
|
</para>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
</para>
|
|
</sect2>
|
|
|
|
</sect1>
|
|
|
|
<sect1 id="release-5.0">
|
|
<title>Release 5.0</title>
|
|
<para><emphasis>Tue 15 October, 2019</emphasis></para>
|
|
|
|
<para>
|
|
&repmgr; 5.0 is a major release.
|
|
</para>
|
|
<para>
|
|
For details on how to upgrade an existing &repmgr; installation, see
|
|
documentation section <link linkend="upgrading-major-version">Upgrading a major version release</link>.
|
|
</para>
|
|
<para>
|
|
If &repmgrd; is in use, a PostgreSQL restart <emphasis>is</emphasis> required;
|
|
in that case we suggest combining this &repmgr; upgrade with the next PostgreSQL
|
|
minor release, which will require a PostgreSQL restart in any case.
|
|
</para>
|
|
|
|
|
|
<sect2>
|
|
<title>Compatibility changes</title>
|
|
|
|
<sect3 id="repmgr-5-0-config-file-parsing">
|
|
<title>Configuration file parsing has been made stricter</title>
|
|
<para>
|
|
&repmgr; now parses <link linkend="configuration-file-format">configuration files</link>
|
|
in the same way that PostgreSQL itself does, which means some files used with
|
|
earlier &repmgr; versions may need slight modification before they can be used
|
|
with &repmgr; 5 and later.
|
|
</para>
|
|
<para>
|
|
The main change is that string parameters should always be enclosed in single quotes.
|
|
</para>
|
|
<para>
|
|
For example, in &repmgr; 4.4 and earlier, the following <filename>repmgr.conf</filename>
|
|
entry was valid:
|
|
<programlisting>
|
|
conninfo=host=node1 user=repmgr dbname=repmgr connect_timeout=2</programlisting>
|
|
This must now be changed to:
|
|
<programlisting>
|
|
conninfo='host=node1 user=repmgr dbname=repmgr connect_timeout=2'</programlisting>
|
|
</para>
|
|
<para>
|
|
Note that simple string identifiers (e.g. <literal>node_name=node1</literal>)
|
|
may remain unquoted, though we recommend always enclosing
|
|
strings in single quotes.
|
|
</para>
|
|
<para>
|
|
Additionally, leading/trailing white space between single quotes will no longer
|
|
be trimmed; the entire string between single quotes will be
|
|
taken literally.
|
|
</para>
|
|
<para>
|
|
Strings enclosed in double quotes (e.g. <literal>node_name="node1"</literal>)
|
|
will now be rejected; previously they were accepted, but the double quotes were
|
|
interpreted as part of the string, which was a frequent cause of confusion.
|
|
</para>
|
|
<para>
|
|
This syntax matches that used by PostgreSQL itself.
|
|
</para>
|
|
</sect3>
|
|
|
|
<sect3>
|
|
<title>Some "repmgr daemon ..." commands renamed</title>
|
|
|
|
<para>
|
|
Some "<command>repmgr daemon ...</command>" commands have been renamed to
|
|
"<command>repmgr service ...</command>" as they have a cluster-wide effect
|
|
and to avoid giving the impression they affect only the local &repmgr; daemon.
|
|
</para>
|
|
<para>
|
|
The following commands are affected:
|
|
|
|
<itemizedlist spacing="compact" mark="bullet">
|
|
|
|
<listitem>
|
|
<simpara>
|
|
<command>repmgr daemon pause</command>
|
|
(now <link linkend="repmgr-service-pause"><command>repmgr service pause</command></link>)
|
|
</simpara>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<simpara>
|
|
<command>repmgr daemon unpause</command>
|
|
(now <link linkend="repmgr-service-unpause"><command>repmgr service unpause</command></link>)
|
|
</simpara>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<simpara>
|
|
<command>repmgr daemon status</command>
|
|
(now <link linkend="repmgr-service-status"><command>repmgr service status</command></link>)
|
|
</simpara>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
</para>
|
|
<para>
|
|
The "<command>repmgr daemon ...</command>" form will still be accepted
|
|
for backwards compatibility.
|
|
</para>
|
|
</sect3>
|
|
|
|
<sect3>
|
|
<title>Some deprecated command line options removed</title>
|
|
<para>
|
|
The following command line options, which have been deprecated since &repmgr; 3.3
|
|
(and which no longer had any effect other than to generate a warning about their use)
|
|
have been removed:
|
|
<itemizedlist spacing="compact" mark="bullet">
|
|
|
|
<listitem>
|
|
<simpara><option>--data-dir</option></simpara>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<simpara><option>--no-conninfo-password</option></simpara>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<simpara><option>--recovery-min-apply-delay</option></simpara>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
</para>
|
|
</sect3>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>General enhancements</title>
|
|
<para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
Support for PostgreSQL 12 added.
|
|
</para>
|
|
<para>
|
|
Beginning with PostgreSQL 12, replication configuration has been integrated
|
|
into the main PostgreSQL configuraton system and the conventional
|
|
<filename>recovery.conf</filename> file is no longer valid.
|
|
</para>
|
|
<para>
|
|
&repmgr; has been modified to be compatible with this change.
|
|
</para>
|
|
<para>
|
|
&repmgr; additionally takes advantage of the new <command>pg_promote()</command>
|
|
function, which enables a standby to be promoted to primary using an SQL
|
|
command.
|
|
</para>
|
|
<para>
|
|
For an overview of general changes to replication configuration, see this blog entry:
|
|
<ulink url="https://www.2ndquadrant.com/en/blog/replication-configuration-changes-in-postgresql-12/">Replication configuration changes in PostgreSQL 12</ulink>
|
|
</para>
|
|
</listitem>
|
|
|
|
|
|
<listitem>
|
|
<para>
|
|
The &repmgr; configuration file is now parsed using
|
|
<command>flex</command>, meaning it will be parsed in
|
|
the same way as PostgreSQL parses its own configuration
|
|
files.
|
|
</para>
|
|
<para>
|
|
This makes configuration file parsing more robust
|
|
and consistent.
|
|
</para>
|
|
<para>
|
|
See item <link linkend="repmgr-5-0-config-file-parsing">Configuration file parsing has been made stricter</link>
|
|
for details.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<link linkend="repmgr-standby-clone"><command>repmgr standby clone</command></link>:
|
|
checks for availability of the &repmgr; extension on the upstream node have
|
|
been improved and error messages improved.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
When executing &repmgr; remotely, if the &repmgr; log level was explicitly
|
|
provided (with <option>-L</option>/<option>--log-level</option>), that log level
|
|
will be passed to the remote &repmgr;.
|
|
</para>
|
|
<para>
|
|
This makes it possible to return log output when executing repmgr
|
|
remotely at a different level to the one defined in the remote
|
|
&repmgr;'s <filename>repmgr.conf</filename>.
|
|
</para>
|
|
<para>
|
|
This is particularly useful when <literal>DEBUG</literal> output is required.
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Bug fixes</title>
|
|
<para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
Check role membership when trying to read <literal>pg_settings</literal>.
|
|
</para>
|
|
<para>
|
|
Previously &repmgr; assumed only superusers could read <literal>pg_settings</literal>,
|
|
but from PostgreSQL 10, all members of the roles <literal>pg_read_all_settings</literal>
|
|
or <literal>pg_monitor</literal> are permitted to do this as well.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
&repmgrd;: Fix handling of upstream node change check.
|
|
</para>
|
|
<para>
|
|
&repmgrd; has a check to see if the upstream node has unexpectedly
|
|
changed, e.g. if the repmgrd service is paused and the PostgreSQL
|
|
instance has been pointed to another node.
|
|
</para>
|
|
<para>
|
|
However this check was relying on the node record on the local node
|
|
being up-to-date, which may not be the case immediately after a
|
|
failover, when the node is still replaying records updated prior
|
|
to the node's own record being updated. In this case it will
|
|
mistakenly assume the node is following the original primary
|
|
and attempt to restart monitoring, which will fail as the original
|
|
primary is no longer available.
|
|
</para>
|
|
<para>
|
|
To prevent this, the node's record on the upstream node is checked
|
|
to see if the reported upstream <literal>node_id</literal> matches
|
|
the expected <literal>node_id</literal>. GitHub #587/#588.
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</para>
|
|
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 id="release-4.4">
|
|
<title>Release 4.4</title>
|
|
<para><emphasis>Thu 27 June, 2019</emphasis></para>
|
|
|
|
<para>
|
|
&repmgr; 4.4 is a major release.
|
|
</para>
|
|
<para>
|
|
For details on how to upgrade an existing &repmgr; installation, see
|
|
documentation section <link linkend="upgrading-major-version">Upgrading a major version release</link>.
|
|
</para>
|
|
<para>
|
|
If &repmgrd; is in use, a PostgreSQL restart <emphasis>is</emphasis> required;
|
|
in that case we suggest combining this &repmgr; upgrade with the next PostgreSQL
|
|
minor release, which will require a PostgreSQL restart in any case.
|
|
</para>
|
|
|
|
|
|
<important>
|
|
<para>
|
|
On Debian-based systems, including Ubuntu, if using &repmgrd;
|
|
please ensure that in the file <filename>/etc/init.d/repmgrd</filename>, the parameter
|
|
<varname>REPMGRD_OPTS</varname> contains "<literal>--daemonize=false</literal>", e.g.:
|
|
<programlisting>
|
|
# additional options
|
|
REPMGRD_OPTS="--daemonize=false"</programlisting>
|
|
</para>
|
|
<para>
|
|
For further details, see <link linkend="repmgrd-configuration-debian-ubuntu">repmgrd configuration on Debian/Ubuntu</link>.
|
|
</para>
|
|
</important>
|
|
|
|
<sect2>
|
|
<title>repmgr client enhancements</title>
|
|
<para>
|
|
<itemizedlist>
|
|
|
|
<listitem>
|
|
<para>
|
|
<link linkend="repmgr-standby-clone"><command>repmgr standby clone</command></link>:
|
|
prevent a standby from being cloned from a witness server (PostgreSQL 9.6 and later only).
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<link linkend="repmgr-witness-register"><command>repmgr witness register</command></link>:
|
|
prevent a witness server from being registered on the replication cluster primary server
|
|
(PostgreSQL 9.6 and later only).
|
|
</para>
|
|
<para>
|
|
Registering a witness on the primary node would defeat the purpose of having a witness server,
|
|
which is intended to remain running even if the cluster's primary goes down.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<link linkend="repmgr-standby-follow"><command>repmgr standby follow</command></link>:
|
|
note that an active, reachable cluster primary is required for this command;
|
|
and provide a more helpful error message if no reachable primary could be found.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
&repmgr;: when executing <link linkend="repmgr-standby-switchover"><command>repmgr standby switchover</command></link>,
|
|
if <option>--siblings-follow</option> is not supplied, list all nodes which repmgr considers
|
|
to be siblings (this will include the witness server, if in use), and
|
|
which will remain attached to the old primary.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
&repmgr;: when executing <link linkend="repmgr-standby-switchover"><command>repmgr standby switchover</command></link>,
|
|
ignore nodes which are unreachable and marked as inactive.
|
|
Previously it would abort if any node was unreachable,
|
|
as that means it was unable to check if repmgrd is running.
|
|
</para>
|
|
<para>
|
|
However if the node has been marked as inactive in the repmgr metadata, it's
|
|
reasonable to assume the node is no longer part of the replication cluster
|
|
and does not need to be checked.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<link linkend="repmgr-standby-switchover"><command>repmgr standby switchover</command></link>
|
|
and <link linkend="repmgr-standby-promote"><command>repmgr standby promote</command></link>:
|
|
when executing with the <option>--dry-run</option> option, continue checks as far as possible
|
|
even if errors are encountered.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<link linkend="repmgr-standby-promote"><command>repmgr standby promote</command></link>:
|
|
add <option>--siblings-follow</option> (similar to
|
|
<link linkend="repmgr-standby-switchover"><command>repmgr standby switchover</command></link>).
|
|
</para>
|
|
<note>
|
|
<para>
|
|
If using &repmgrd;, when invoking
|
|
<command>repmgr standby promote</command> (either directly via
|
|
the <option>promote_command</option>, or in a script called
|
|
via <option>promote_command</option>), <option>--siblings-follow</option>
|
|
<emphasis>must not</emphasis> be included as a
|
|
command line option for <link linkend="repmgr-standby-promote"><command>repmgr standby promote</command></link>.
|
|
</para>
|
|
</note>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<link linkend="repmgr-standby-switchover"><command>repmgr standby switchover</command></link>:
|
|
add <option>--repmgrd-force-unpause</option> to unpause all &repmgrd; instances after executing a switchover.
|
|
This will ensure that any &repmgrd; instances which were paused before the switchover will be
|
|
unpaused.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<link linkend="repmgr-service-status"><command>repmgr daemon status</command></link>:
|
|
make output similar to that of
|
|
<link linkend="repmgr-cluster-show"><command>repmgr cluster show</command></link>
|
|
for consistency and to make it easier to identify nodes not in the expected
|
|
state.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<link linkend="repmgr-cluster-show"><command>repmgr cluster show</command></link>:
|
|
display each node's timeline ID (PostgreSQL 9.6 and later only).
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<link linkend="repmgr-cluster-show"><command>repmgr cluster show</command></link>
|
|
and <link linkend="repmgr-service-status"><command>repmgr daemon status</command></link>:
|
|
show the upstream node name as reported by each individual node - this helps visualise
|
|
situations where the cluster is in an unexpected state, and provide a better idea of the
|
|
actual cluster state.
|
|
</para>
|
|
<para>
|
|
For example, if a cluster has divided somehow and a set of nodes are
|
|
following a new primary, when running either of these commands, &repmgr;
|
|
will now show the name of the primary those nodes are actually
|
|
following, rather than the now outdated node name recorded
|
|
on the other side of the "split". A warning will also be issued
|
|
about the unexpected situation.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<link linkend="repmgr-cluster-show"><command>repmgr cluster show</command></link>
|
|
and <link linkend="repmgr-service-status"><command>repmgr daemon status</command></link>:
|
|
check if a node is attached to its advertised upstream node, and issue a
|
|
warning if the node is not attached.
|
|
</para>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>repmgrd enhancements</title>
|
|
<para>
|
|
<itemizedlist>
|
|
|
|
<listitem>
|
|
<para>
|
|
On the primary node, &repmgrd; is now able to monitor standby connections and,
|
|
if the number of nodes connected falls below a certain (configurable) value,
|
|
execute a custom script.
|
|
</para>
|
|
<para>
|
|
This provided an additional method for fencing an isolated primary node, and/or taking
|
|
other action if one or more standys become disconnected.
|
|
</para>
|
|
<para>
|
|
See section <link linkend="repmgrd-primary-child-disconnection">Monitoring standby disconnections on the primary node</link>
|
|
for more details.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
In a failover situation, &repmgrd; nodes on the standbys of the failed primary
|
|
are now able confirm among themselves that none can still see the primary
|
|
before continuing with the failover.
|
|
</para>
|
|
<para>
|
|
The <filename>repmgr.conf</filename> option <option>primary_visibility_consensus</option> must
|
|
be set to <literal>true</literal> to enable this functionality.
|
|
</para>
|
|
<para>
|
|
See section <xref linkend="repmgrd-primary-visibility-consensus"/>
|
|
for more details.
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Bug fixes</title>
|
|
<para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
Ensure BDR2-specific functionality cannot be used on BDR3 and later.
|
|
</para>
|
|
<para>
|
|
The BDR support present in &repmgr; is for specific BDR2 use cases.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
&repmgr;: when executing <link linkend="repmgr-standby-clone"><command>repmgr standby clone</command></link>
|
|
in <option>--dry-run</option> mode, ensure provision of the <option>--force</option> option
|
|
does not result in an existing data directory being modified in any way.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
&repmgr;: when executing <link linkend="repmgr-primary-register"><command>repmgr primary register</command></link>
|
|
with the <option>--force</option> option, if another primary record exists but the associated node is
|
|
unreachable (or running as a standby), set that node's record to inactive to enable the current node
|
|
to be registered as a primary.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
&repmgr;: when executing <link linkend="repmgr-standby-clone"><command>repmgr standby clone</command></link>
|
|
with the <option>--upstream-conninfo</option>, ensure that <varname>application_name</varname>
|
|
is set correctly in <varname>primary_conninfo</varname>.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
&repmgr;: when executing <link linkend="repmgr-standby-switchover"><command>repmgr standby switchover</command></link>,
|
|
don't abort if one or more nodes are not reachable <emphasis>and</emphasis>
|
|
they are marked as inactive.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
&repmgr;: canonicalize the data directory path when parsing the configuration file, so
|
|
the provided path matches the path PostgreSQL reports as its data directory.
|
|
Otherwise, if e.g. the data directory is configured with a trailing slash,
|
|
<link linkend="repmgr-node-check"><command>repmgr node check --data-directory-config</command></link>
|
|
will return a spurious error.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
&repmgrd;: fix memory leak which occurs while the monitored PostgreSQL node is <emphasis>not</emphasis>
|
|
running.
|
|
</para>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
</para>
|
|
</sect2>
|
|
|
|
|
|
<sect2>
|
|
<title>Other</title>
|
|
<para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
The &repmgr; documentation has been converted to DocBook XML format,
|
|
as currently used by the main PostgreSQL project.
|
|
This means it can now be built against any PostgreSQL version from 9.5
|
|
(previously it was not possible to build the documentation against
|
|
PostgreSQL 10 or later), and makes it easier to provide the documentation
|
|
in other formats such as PDF.
|
|
</para>
|
|
<para>
|
|
For further details see: <xref linkend="installation-build-repmgr-docs"/>
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</para>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
|
|
<sect1 id="release-4.3">
|
|
<title>Release 4.3</title>
|
|
<para><emphasis>Tue April 2, 2019</emphasis></para>
|
|
<para>
|
|
&repmgr; 4.3 is a major release.
|
|
</para>
|
|
<para>
|
|
For details on how to upgrade an existing &repmgr; installation, see
|
|
documentation section <link linkend="upgrading-major-version">Upgrading a major version release</link>.
|
|
</para>
|
|
<para>
|
|
If &repmgrd; is in use, a PostgreSQL restart <emphasis>is</emphasis> required;
|
|
in that case we suggest combining this &repmgr; upgrade with the next PostgreSQL
|
|
minor release, which will require a PostgreSQL restart in any case.
|
|
</para>
|
|
|
|
|
|
<important>
|
|
<para>
|
|
On Debian-based systems, including Ubuntu, if using &repmgrd;
|
|
please ensure that in the file <filename>/etc/init.d/repmgrd</filename>, the parameter
|
|
<varname>REPMGRD_OPTS</varname> contains "<literal>--daemonize=false</literal>", e.g.:
|
|
<programlisting>
|
|
# additional options
|
|
REPMGRD_OPTS="--daemonize=false"</programlisting>
|
|
</para>
|
|
<para>
|
|
For further details, see <link linkend="repmgrd-configuration-debian-ubuntu">repmgrd configuration on Debian/Ubuntu</link>.
|
|
</para>
|
|
</important>
|
|
|
|
<sect2>
|
|
<title>repmgr client enhancements</title>
|
|
<para>
|
|
<itemizedlist>
|
|
|
|
<listitem>
|
|
<para>
|
|
<link linkend="repmgr-standby-follow"><command>repmgr standby follow</command></link>:
|
|
option <option>--upstream-node-id</option> can now be used to specify another standby
|
|
to follow.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<link linkend="repmgr-standby-follow"><command>repmgr standby follow</command></link>:
|
|
verify that it is actually possible to follow another node.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<link linkend="repmgr-node-rejoin"><command>repmgr node rejoin</command></link>:
|
|
verify that it is actually possible to attach the node to the current primary.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
New commands <link linkend="repmgr-daemon-start"><command>repmgr daemon start</command></link> and
|
|
<link linkend="repmgr-daemon-stop"><command>repmgr daemon stop</command></link>:
|
|
these provide a standardized way of starting and stopping &repmgrd;.
|
|
GitHub #528.
|
|
</para>
|
|
<note>
|
|
<para>
|
|
These commands require the configuration file settings
|
|
<varname>repmgrd_service_start_command</varname> and <varname>repmgrd_service_stop_command</varname>
|
|
in <filename>repmgr.conf</filename> to be set.
|
|
</para>
|
|
</note>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<link linkend="repmgr-service-status"><command>repmgr daemon status</command></link>
|
|
additionally displays the node priority and the interval (in seconds) since the
|
|
&repmgrd; instance last verified its upstream node was available.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
Add <option>--compact</option> option to <command><link linkend="repmgr-cluster-show">repmgr cluster show</link></command> (GitHub #521).
|
|
</para>
|
|
<para>
|
|
This makes it easier to copy the output into emails, chats etc. as a compact table.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<command><link linkend="repmgr-cluster-show">repmgr cluster show</link></command>:
|
|
differentiate between unreachable nodes and nodes which are running but rejecting connections.
|
|
</para>
|
|
<para>
|
|
This makes it possible to see whether a node is unreachable at network level,
|
|
or if it is running but rejecting connections for some reason.
|
|
</para>
|
|
</listitem>
|
|
|
|
|
|
<listitem>
|
|
<para>
|
|
Add <option>--dry-run</option> to <command><link linkend="repmgr-standby-promote">repmgr standby promote</link></command> (GitHub #522).
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<command>repmgr --version-number</command> outputs the "raw"
|
|
repmgr version number (e.g. <literal>40300</literal>). This is intended
|
|
for use by scripts etc. requiring an easily parseable representation
|
|
of the &repmgr; version.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<link linkend="repmgr-node-check"><command>repmgr node check --data-directory-config</command></link>
|
|
option added; this is to confirm &repmgr; is correctly configured. GitHub #523.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
Add check to <link linkend="repmgr-standby-switchover"><command>repmgr standby switchover</command></link>
|
|
to ensure the data directory on the demotion candidate is configured correctly in <filename>repmgr.conf</filename>.
|
|
This is to ensure that &repmgr;, when remotely executed on the demotion candidate, can correctly verify
|
|
that PostgreSQL on the demotion candidate was shut down cleanly. GitHub #523.
|
|
</para>
|
|
</listitem>
|
|
|
|
|
|
</itemizedlist>
|
|
</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>repmgrd enhancements</title>
|
|
<para>
|
|
<itemizedlist>
|
|
|
|
<listitem>
|
|
<para>
|
|
&repmgrd; will no longer consider nodes where &repmgrd;
|
|
is not running as promotion candidates.
|
|
</para>
|
|
<para>
|
|
Previously, if &repmgrd; was not running on a node, but
|
|
that node qualified as the promotion candidate, it would never be promoted due to
|
|
the absence of a running &repmgrd;.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
Add option <option>connection_check_type</option> to enable selection of the method
|
|
&repmgrd; uses to determine whether the upstream node is available.
|
|
</para>
|
|
<para>
|
|
Possible values are <literal>ping</literal> (default; uses <command>PQping()</command> to
|
|
determine server availability), <literal>connection</literal> (attempst to make a new connection to
|
|
the upstream node), and <literal>query</literal> (determines server availability
|
|
by executing an SQL statement on the node via the existing connection).
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
New configuration option <link linkend="repmgrd-failover-validation"><option>failover_validation_command</option></link>
|
|
to allow an external mechanism to validate the failover decision made by &repmgrd;.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
New configuration option <link linkend="repmgrd-standby-disconnection-on-failover"><option>standby_disconnect_on_failover</option></link>
|
|
to force standbys to disconnect their WAL receivers before making a failover decision.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
In a failover situation, &repmgrd; will not attempt to promote a
|
|
node if another primary has already appeared (e.g. by being promoted manually).
|
|
GitHub #420.
|
|
</para>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Bug fixes</title>
|
|
<para>
|
|
<itemizedlist>
|
|
|
|
<listitem>
|
|
<para>
|
|
<command><link linkend="repmgr-cluster-show">repmgr cluster show</link></command>:
|
|
fix display of node IDs with multiple digits.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
ensure <command><link linkend="repmgr-primary-unregister">repmgr primary unregister</link></command>
|
|
behaves correctly when executed on a witness server. GitHub #548.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
ensure <command><link linkend="repmgr-standby-register">repmgr standby register</link></command>
|
|
fails when <option>--upstream-node-id</option> is the same as the local node ID.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
&repmgr;: when executing <link linkend="repmgr-standby-clone"><command>repmgr standby clone</command></link>,
|
|
recheck primary/upstream connection(s) after the data copy operation is complete, as these may
|
|
have gone away.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
&repmgr;: when executing <command><link linkend="repmgr-standby-switchover">repmgr standby switchover</link></command>,
|
|
prevent escaping issues with connection URIs when executing <command><link linkend="repmgr-node-rejoin">repmgr node rejoin</link></command>
|
|
on the demotion candidate. GitHub #525.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
&repmgr;: when executing <link linkend="repmgr-standby-switchover"><command>repmgr standby switchover</command></link>,
|
|
verify the standby (promotion candidate) is currently attached to the primary (demotion candidate). GitHub #519.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
&repmgr;: when executing <link linkend="repmgr-standby-switchover"><command>repmgr standby switchover</command></link>,
|
|
avoid a potential race condition when comparing received WAL on the standby to the primary's shutdown location,
|
|
as the standby's walreceiver may not have yet flushed all received WAL to disk. GitHub #518.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
&repmgr;: when executing <command><link linkend="repmgr-witness-register">repmgr witness register</link></command>,
|
|
check the node to connected is actually the primary (i.e. not the witness server). GitHub #528.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<command><link linkend="repmgr-node-check">repmgr node check</link></command>
|
|
will only consider physical replication slots, as the purpose
|
|
of slot checks is to warn about potential issues with
|
|
streaming replication standbys which are no longer attached.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
&repmgrd;: on a cascaded standby, don't fail over if
|
|
<literal>failover=manual</literal>. GitHub #531.
|
|
</para>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
</para>
|
|
</sect2>
|
|
|
|
</sect1>
|
|
|
|
<sect1 id="release-4.2">
|
|
<title>Release 4.2</title>
|
|
<para><emphasis>Wed October 24, 2018</emphasis></para>
|
|
|
|
<para>
|
|
&repmgr; 4.2 is a major release, with the main new feature being the
|
|
ability to <link linkend="repmgrd-pausing">pause repmgrd</link>, e.g. during planned maintenance
|
|
operations. Various other usability enhancements and a couple of bug fixes are also included;
|
|
see notes below for details.
|
|
</para>
|
|
<para>
|
|
A restart of the PostgreSQL server <emphasis>is</emphasis> required
|
|
for this release. For detailed upgrade instructions, see
|
|
<link linkend="upgrading-major-version">Upgrading a major version release</link>.
|
|
</para>
|
|
|
|
<important>
|
|
<para>
|
|
On Debian-based systems, including Ubuntu, if using &repmgrd;
|
|
please ensure that the in the file <filename>/etc/init.d/repmgrd</filename>, the parameter
|
|
<varname>REPMGRD_OPTS</varname> contains "<literal>--daemonize=false</literal>", e.g.:
|
|
<programlisting>
|
|
# additional options
|
|
REPMGRD_OPTS="--daemonize=false"</programlisting>
|
|
</para>
|
|
<para>
|
|
For further details, see <link linkend="repmgrd-configuration-debian-ubuntu">repmgrd daemon configuration on Debian/Ubuntu</link>.
|
|
</para>
|
|
</important>
|
|
|
|
<sect2>
|
|
<title>Configuration file changes</title>
|
|
<para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
New parameter <varname>shutdown_check_timeout</varname> (default: 60 seconds) added;
|
|
this provides an explicit timeout for
|
|
<command><link linkend="repmgr-standby-switchover">repmgr standby switchover</link></command>
|
|
to check that the demotion candidate (current primary) has shut down. Previously, the parameters
|
|
<literal>reconnect_attempts</literal> and <literal>reconnect_interval</literal>
|
|
were used to calculate a timeout, but these are actually
|
|
intended for primary failure detection. (GitHub #504).
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
New parameter <varname>repmgr_bindir</varname> added, to facilitate remote invocation of repmgr
|
|
when the repmgr binary is located somewhere other than the PostgreSQL binary directory, as it
|
|
cannot be assumed all package maintainers will install &repmgr; there.
|
|
</para>
|
|
<para>
|
|
This parameter is optional; if not set (the default), &repmgr; will fall back
|
|
to <option>pg_bindir</option> (if set).
|
|
</para>
|
|
<para>
|
|
(GitHub #246).
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>repmgr enhancements</title>
|
|
<para>
|
|
<itemizedlist>
|
|
|
|
<listitem>
|
|
<para>
|
|
<command><link linkend="repmgr-cluster-cleanup">repmgr cluster cleanup</link></command>
|
|
now accepts the <option>--node-id</option> option to delete records for only one
|
|
node. (GitHub #493).
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
When running
|
|
<command><link linkend="repmgr-cluster-matrix">repmgr cluster matrix</link></command> and
|
|
<command><link linkend="repmgr-cluster-crosscheck">repmgr cluster crosscheck</link></command>,
|
|
&repmgr; will report nodes unreachable via SSH, and emit return code <literal>ERR_BAD_SSH</literal>.
|
|
(GitHub #246).
|
|
</para>
|
|
<note>
|
|
<para>
|
|
Users relying on
|
|
<command><link linkend="repmgr-cluster-crosscheck">repmgr cluster crosscheck</link></command>
|
|
to return a non-zero return code as a way of detecting connectivity errors should be aware
|
|
that <literal>ERR_BAD_SSH</literal> will be returned if there is an SSH connection error
|
|
from the node where the command is executed, even if the command is able to establish
|
|
that PostgreSQL connectivity is fine. Therefore the exact return code should be checked
|
|
to determine what kind of connectivity error has been detected.
|
|
</para>
|
|
</note>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
</para>
|
|
</sect2>
|
|
|
|
|
|
<sect2>
|
|
<title>repmgrd enhancements</title>
|
|
<para>
|
|
<itemizedlist>
|
|
|
|
<listitem>
|
|
<para>
|
|
&repmgrd; can now be "paused", i.e. instructed
|
|
not to take any action such as a failover, even if the prerequisites for such an
|
|
action are detected.
|
|
</para>
|
|
<para>
|
|
This removes the need to stop &repmgrd; on all nodes when
|
|
performing a planned operation such as a switchover.
|
|
</para>
|
|
<para>
|
|
For further details, see <link linkend="repmgrd-pausing">Pausing repmgrd</link>.
|
|
</para>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Bug fixes</title>
|
|
<para>
|
|
<itemizedlist>
|
|
|
|
<listitem>
|
|
<para>
|
|
&repmgr;: fix "Missing replication slots" label in
|
|
<command><link linkend="repmgr-node-check">repmgr node check</link></command>. (GitHub #507)
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
&repmgrd;: fix parsing of <option>-d/--daemonize</option> option.
|
|
</para>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
</para>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
<sect1 id="release-4.1.1">
|
|
<title>Release 4.1.1</title>
|
|
<para><emphasis>Wed September 5, 2018</emphasis></para>
|
|
<para>
|
|
repmgr 4.1.1 contains a number of usability enhancements and bug fixes.
|
|
</para>
|
|
<para>
|
|
We recommend upgrading to this version as soon as possible.
|
|
This release can be installed as a simple package upgrade from repmgr 4.0 ~ 4.1.0;
|
|
&repmgrd; (if running) should be restarted.
|
|
See <xref linkend="upgrading-repmgr"/> for more details.
|
|
</para>
|
|
|
|
<sect2>
|
|
<title>repmgr enhancements</title>
|
|
<para>
|
|
<itemizedlist>
|
|
|
|
<listitem>
|
|
<para>
|
|
<command><link linkend="repmgr-standby-switchover">repmgr standby switchover --dry-run</link></command>
|
|
no longer copies external configuration files to test they can be copied; this avoids making
|
|
any changes to the target system. (GitHub #491).
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<command><link linkend="repmgr-cluster-cleanup">repmgr cluster cleanup</link></command>:
|
|
add <literal>cluster_cleanup</literal> event. (GitHub #492).
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<command><link linkend="repmgr-standby-switchover">repmgr standby switchover</link></command>:
|
|
improve detection of free walsenders. (GitHub #495).
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
Improve messages emitted during
|
|
<command><link linkend="repmgr-standby-promote">repmgr standby promote</link></command>.
|
|
</para>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
</para>
|
|
</sect2>
|
|
|
|
|
|
<sect2>
|
|
<title>repmgrd enhancements</title>
|
|
<para>
|
|
<itemizedlist>
|
|
|
|
<listitem>
|
|
<para>
|
|
Always reopen the log file after
|
|
receiving <literal>SIGHUP</literal>. Previously this only happened if
|
|
a configuration file change was detected.
|
|
(GitHub #485).
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
Report version number <emphasis>after</emphasis>
|
|
logger initialisation. (GitHub #487).
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
Improve cascaded standby failover handling. (GitHub #480).
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
Improve reconnection handling after brief network outages; if
|
|
monitoring data being collected, this could lead to orphaned
|
|
sessions on the primary. (GitHub #480).
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
Check <varname>promote_command</varname> and <varname>follow_command</varname>
|
|
are defined when reloading configuration. These were checked on startup but
|
|
not reload by &repmgrd;, which made it possible to
|
|
make &repmgrd; with invalid values. It's unlikely
|
|
anyone would want to do this, but we should make it impossible anyway.
|
|
(GitHub #486).
|
|
</para>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Other</title>
|
|
<para>
|
|
<itemizedlist>
|
|
|
|
<listitem>
|
|
<para>
|
|
Text of any failed queries will now be logged as <literal>ERROR</literal> to assist
|
|
logfile analysis at log levels higher than <literal>DEBUG</literal>.
|
|
(GitHub #498).
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Bug fixes</title>
|
|
<para>
|
|
<itemizedlist>
|
|
|
|
<listitem>
|
|
<para>
|
|
<command><link linkend="repmgr-node-rejoin">repmgr node rejoin</link></command>:
|
|
remove new upstream's replication slot if it still exists on the rejoined
|
|
standby. (GitHub #499).
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
&repmgrd;: fix startup on witness node when local data is stale. (GitHub #488, #489).
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
Truncate version string reported by PostgreSQL if necessary; some
|
|
distributions insert additional detail after the actual version.
|
|
(GitHub #490).
|
|
</para>
|
|
</listitem>
|
|
|
|
|
|
</itemizedlist>
|
|
</para>
|
|
</sect2>
|
|
|
|
|
|
</sect1>
|
|
|
|
|
|
|
|
<sect1 id="release-4.1.0">
|
|
<title>Release 4.1.0</title>
|
|
<para><emphasis>Tue July 31, 2018</emphasis></para>
|
|
<para>
|
|
&repmgr; 4.1.0 introduces some changes to &repmgrd;
|
|
behaviour and some additional configuration parameters.
|
|
</para>
|
|
<para>
|
|
This release can be installed as a simple package upgrade from repmgr 4.0 ~ 4.0.6.
|
|
The following post-upgrade steps must be carried out:
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
Execute <command>ALTER EXTENSION repmgr UPDATE</command>
|
|
on the primary server in the database where &repmgr; is installed.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
&repmgrd; must be restarted on all nodes where it is running.
|
|
</para>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
|
|
A restart of the PostgreSQL server is <emphasis>not</emphasis> required
|
|
for this release (unless upgrading from repmgr 3.x).
|
|
</para>
|
|
<para>
|
|
See <xref linkend="upgrading-repmgr-extension"/> for more details.
|
|
</para>
|
|
|
|
<para>
|
|
Configuration changes are backwards-compatible and no changes to
|
|
<filename>repmgr.conf</filename> are required. However users should
|
|
review the changes listed below.
|
|
</para>
|
|
|
|
<note>
|
|
<para>
|
|
<emphasis>Repository changes</emphasis>
|
|
</para>
|
|
<para>
|
|
Coinciding with this release, the 2ndQuadrant repository structure has changed.
|
|
See section <xref linkend="installation-packages"/> for details, particularly
|
|
if you are using a RPM-based system.
|
|
</para>
|
|
</note>
|
|
|
|
<sect2>
|
|
<title>Configuration file changes</title>
|
|
|
|
<para>
|
|
<itemizedlist>
|
|
|
|
<listitem>
|
|
<para>
|
|
Default for <xref linkend="repmgr-conf-log-level"/> is now <option>INFO</option>.
|
|
This produces additional informative log output, without creating excessive additional
|
|
log file volume, and matches the setting assumed for examples in the documentation.
|
|
(GitHub #470).
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<varname>recovery_min_apply_delay</varname> now accepts a minimum value
|
|
of <literal>zero</literal> (GitHub #448).
|
|
</para>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
|
|
<sect2>
|
|
<title>repmgr enhancements</title>
|
|
<para>
|
|
<itemizedlist>
|
|
|
|
<listitem>
|
|
<para>
|
|
<application>repmgr</application>: always exit with an error if an unrecognised
|
|
command line option is provided. This matches the behaviour of other PostgreSQL
|
|
utilities such as <application>psql</application>. (GitHub #464).
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<application>repmgr</application>: add <option>-q/--quiet</option> option to suppress non-error
|
|
output. (GitHub #468).
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<command><link linkend="repmgr-cluster-show">repmgr cluster show</link></command>,
|
|
<command><link linkend="repmgr-node-check">repmgr node check</link></command> and
|
|
<command><link linkend="repmgr-node-status">repmgr node status</link></command>
|
|
return non-zero exit code if node status issues detected. (GitHub #456).
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
Add <option>--csv</option> output option for
|
|
<command><link linkend="repmgr-cluster-event">repmgr cluster event</link></command>.
|
|
(GitHub #471).
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<command><link linkend="repmgr-witness-unregister">repmgr witness unregister</link></command>
|
|
can be run on any node, by providing the ID of the witness node with <option>--node-id</option>.
|
|
(GitHub #472).
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<command><link linkend="repmgr-standby-switchover">repmgr standby switchover</link></command>
|
|
will refuse to run if an exclusive backup is taking place on the current primary.
|
|
(GitHub #476).
|
|
</para>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>repmgrd enhancements</title>
|
|
<para>
|
|
<itemizedlist>
|
|
|
|
<listitem>
|
|
<para>
|
|
&repmgrd;: create a PID file by default
|
|
(GitHub #457). For details, see <xref linkend="repmgrd-pid-file"/>.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
&repmgrd;: daemonize process by default.
|
|
In case, for whatever reason, the user does not wish to daemonize the
|
|
process, provide <option>--daemonize=false</option>.
|
|
(GitHub #458).
|
|
</para>
|
|
</listitem>
|
|
|
|
|
|
</itemizedlist>
|
|
</para>
|
|
</sect2>
|
|
|
|
|
|
<sect2>
|
|
<title>Bug fixes</title>
|
|
<para>
|
|
<itemizedlist>
|
|
|
|
<listitem>
|
|
<para>
|
|
<command><link linkend="repmgr-standby-register">repmgr standby register --wait-sync</link></command>:
|
|
fix behaviour when no timeout provided.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<command><link linkend="repmgr-cluster-cleanup">repmgr cluster cleanup</link></command>:
|
|
add missing help options. (GitHub #461/#462).
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
Ensure witness node follows new primary after switchover. (GitHub #453).
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<command><link linkend="repmgr-node-check">repmgr node check</link></command> and
|
|
<command><link linkend="repmgr-node-status">repmgr node status</link></command>:
|
|
fix witness node handling. (GitHub #451).
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
When using <command><link linkend="repmgr-standby-clone">repmgr standby clone</link></command>
|
|
with <option>--recovery-conf-only</option> and replication slots, ensure
|
|
<varname>primary_slot_name</varname> is set correctly. (GitHub #474).
|
|
</para>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
</para>
|
|
</sect2>
|
|
|
|
</sect1>
|
|
|
|
<sect1 id="release-4.0.6">
|
|
<title>Release 4.0.6</title>
|
|
<para><emphasis>Thu June 14, 2018</emphasis></para>
|
|
<para>
|
|
&repmgr; 4.0.6 contains a number of bug fixes and usability enhancements.
|
|
</para>
|
|
<para>
|
|
We recommend upgrading to this version as soon as possible.
|
|
This release can be installed as a simple package upgrade from repmgr 4.0 ~ 4.0.5;
|
|
&repmgrd; (if running) should be restarted. See <xref linkend="upgrading-repmgr"/>
|
|
for more details.
|
|
</para>
|
|
|
|
<sect2>
|
|
<title>Usability enhancements</title>
|
|
|
|
<para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
<command><link linkend="repmgr-cluster-crosscheck">repmgr cluster crosscheck</link></command> and
|
|
<command><link linkend="repmgr-cluster-matrix">repmgr cluster matrix</link></command>:
|
|
return non-zero exit code if node connection issues detected (GitHub #447)
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<command><link linkend="repmgr-standby-clone">repmgr standby clone</link></command>:
|
|
Improve handling of external configuration file copying, including consideration in
|
|
<option>--dry-run</option> check
|
|
(GitHub #443)
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
When using <option>--dry-run</option>, force log level to <literal>INFO</literal>
|
|
to ensure output will always be displayed
|
|
(GitHub #441)
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<command><link linkend="repmgr-standby-clone">repmgr standby clone</link></command>:
|
|
Improve documentation of <option>--recovery-conf-only</option> mode
|
|
(GitHub #438)
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<command><link linkend="repmgr-standby-clone">repmgr standby clone</link></command>:
|
|
Don't require presence of <varname>user</varname> parameter in conninfo string
|
|
(GitHub #437)
|
|
</para>
|
|
</listitem>
|
|
|
|
|
|
</itemizedlist>
|
|
</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Bug fixes</title>
|
|
<para>
|
|
|
|
<itemizedlist>
|
|
|
|
<listitem>
|
|
<para>
|
|
<command><link linkend="repmgr-witness-register">repmgr witness register</link></command>:
|
|
prevent registration of a witness server with the same name as an existing node
|
|
</para>
|
|
</listitem>
|
|
|
|
|
|
<listitem>
|
|
<para>
|
|
<command><link linkend="repmgr-standby-follow">repmgr standby follow</link></command>:
|
|
check node has actually connected to new primary before reporting success
|
|
(GitHub #444)
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<command><link linkend="repmgr-node-rejoin">repmgr node rejoin</link></command>:
|
|
Fix bug when parsing <option>--config-files</option> parameter
|
|
(GitHub #442)
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
&repmgrd;: ensure local node is counted as quorum member
|
|
(GitHub #439)
|
|
</para>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
</para>
|
|
</sect2>
|
|
|
|
</sect1>
|
|
|
|
<sect1 id="release-4.0.5">
|
|
<title>Release 4.0.5</title>
|
|
<para><emphasis>Wed May 2, 2018</emphasis></para>
|
|
<para>
|
|
&repmgr; 4.0.5 contains a number of usability enhancements related to
|
|
<application>pg_rewind</application> usage, <filename>recovery.conf</filename>
|
|
generation and (in &repmgrd;) handling of various
|
|
corner-case situations, as well as a number of bug fixes.
|
|
</para>
|
|
|
|
<sect2>
|
|
<title>Usability enhancements</title>
|
|
|
|
<para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
Various documentation improvements, with particular emphasis on
|
|
the importance of setting appropriate <link linkend="configuration-file-service-commands">service commands</link>
|
|
instead of relying on <application>pg_ctl</application>.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
Poll demoted primary after restart as a standby during a switchover operation (GitHub #408).
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
Add configuration parameter <option>config_directory</option> (GitHub #424).
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
Add sanity check if <option>--upstream-node-id</option> not supplied when executing
|
|
<xref linkend="repmgr-standby-register"/> (GitHub #395).
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
Enable <link linkend="repmgr-node-rejoin-pg-rewind">pg_rewind</link> to be used with
|
|
PostgreSQL 9.3/9.4 (GitHub #413).
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
When generating replication connection strings, set <literal>dbname=replication</literal>
|
|
if appropriate (GitHub #421).
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
Enable provision of <option>archive_cleanup_command</option> in <filename>recovery.conf</filename>
|
|
(GitHub #416).
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
Actively check for node to <link linkend="repmgr-node-rejoin">rejoin</link> cluster (GitHub #415).
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
&repmgrd;: set <literal>connect_timeout=2</literal> (if not explicitly set)
|
|
when pinging a server.
|
|
</para>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Bug fixes</title>
|
|
<para>
|
|
|
|
<itemizedlist>
|
|
|
|
<listitem>
|
|
<para>
|
|
Fix display of conninfo parsing error messages.
|
|
</para>
|
|
</listitem>
|
|
|
|
|
|
<listitem>
|
|
<para>
|
|
Fix minimum accepted value for <varname>degraded_monitoring_timeout</varname> (GitHub #411).
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
Fix superuser password handling (GitHub #400)
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
Fix parsing of <varname>archive_ready_critical</varname> configuration file parameter (GitHub #426).
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
Fix <command><link linkend="repmgr-cluster-crosscheck">repmgr cluster crosscheck</link></command>
|
|
output (GitHub #389)
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
Fix memory leaks in witness code (GitHub #402).
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
&repmgrd;: handle <command>pg_ctl promote</command> timeout (GitHub #425).
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
&repmgrd;: handle failover situation with only two nodes in the primary
|
|
location, and at least one node in another location (GitHub #407).
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
&repmgrd;: prevent standby connection handle from going stale.
|
|
</para>
|
|
</listitem>
|
|
|
|
|
|
|
|
</itemizedlist>
|
|
</para>
|
|
</sect2>
|
|
|
|
</sect1>
|
|
|
|
|
|
<sect1 id="release-4.0.4">
|
|
<title>Release 4.0.4</title>
|
|
<para><emphasis>Fri Mar 9, 2018</emphasis></para>
|
|
|
|
<para>
|
|
&repmgr; 4.0.4 contains some bug fixes and and a number of
|
|
usability enhancements related to logging/diagnostics,
|
|
event notifications and pre-action checks.
|
|
</para>
|
|
<para>
|
|
This release can be installed as a simple package upgrade from repmgr 4.0 ~ 4.0.3;
|
|
&repmgrd; (if running) should be restarted. See <xref linkend="upgrading-repmgr"/>
|
|
for more details.
|
|
</para>
|
|
|
|
<note>
|
|
<para>
|
|
It is not possible to perform a switchover where the demotion candidate is
|
|
running &repmgr; 4.0.2 or lower; all nodes should be upgraded to the latest version (4.0.4).
|
|
This is due to additional checks introduced in 4.0.3 which require the presence of
|
|
4.0.3 or later versions on all nodes.
|
|
</para>
|
|
</note>
|
|
|
|
<sect2>
|
|
<title>Usability enhancements</title>
|
|
|
|
<para>
|
|
<itemizedlist>
|
|
|
|
<listitem>
|
|
<para>
|
|
add <command><link linkend="repmgr-standby-clone">repmgr standby clone --recovery-conf-only</link></command>
|
|
option to enable integration of a standby cloned from another source into a &repmgr; cluster (GitHub #382)
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
remove restriction on using replication slots when cloning from a Barman server (GitHub #379)
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
make <command><link linkend="repmgr-standby-promote">repmgr standby promote</link></command>
|
|
timeout values configurable (GitHub #387)
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
add missing options to main <literal>--help</literal> output (GitHub #391, #392)
|
|
</para>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Bug fixes</title>
|
|
<para>
|
|
|
|
<itemizedlist>
|
|
|
|
<listitem>
|
|
<para>
|
|
ensure <command><link linkend="repmgr-node-rejoin">repmgr node rejoin</link></command>
|
|
honours the <option>--dry-run</option> option (GitHub #383)
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
improve replication slot warnings generated by
|
|
<command><link linkend="repmgr-node-status">repmgr node status</link></command>
|
|
(GitHub #385)
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
fix --superuser handling when cloning a standby (GitHub #380)
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
&repmgrd;: improve detection of status change from primary to
|
|
standby
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
&repmgrd;: improve reconnection to the local node after a
|
|
failover (previously a connection error due to the node starting up was being
|
|
interpreted as the node being unavailable)
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
&repmgrd;: when running on a witness server, correctly connect
|
|
to new primary after a failover
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
&repmgrd;: add <link linkend="event-notifications">event notification</link>
|
|
<literal>repmgrd_shutdown</literal> (GitHub #393)
|
|
</para>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
|
|
</para>
|
|
</sect2>
|
|
|
|
</sect1>
|
|
|
|
<sect1 id="release-4.0.3">
|
|
<title>Release 4.0.3</title>
|
|
<para><emphasis>Thu Feb 15, 2018</emphasis></para>
|
|
|
|
<para>
|
|
&repmgr; 4.0.3 contains some bug fixes and and a number of
|
|
usability enhancements related to logging/diagnostics,
|
|
event notifications and pre-action checks.
|
|
</para>
|
|
|
|
<para>
|
|
This release can be installed as a simple package upgrade from repmgr 4.0 ~ 4.0.2;
|
|
repmgrd (if running) should be restarted.
|
|
</para>
|
|
<note>
|
|
<para>
|
|
It is not possible to perform a switchover where the demotion candidate is
|
|
running &repmgr; 4.0.2 or lower; all nodes should be upgraded to 4.0.3. This is due
|
|
to additional checks introduced in 4.0.3 which require the presence of
|
|
4.0.3 or later versions on all nodes.
|
|
</para>
|
|
</note>
|
|
<sect2>
|
|
<title>Usability enhancements</title>
|
|
|
|
<para>
|
|
<itemizedlist>
|
|
|
|
<listitem>
|
|
<para>
|
|
improve <command><link linkend="repmgr-standby-switchover">repmgr standby switchover</link></command>
|
|
behaviour when <command>pg_ctl</command> is used to control the server and logging output is
|
|
not explicitly redirected
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
improve <command><link linkend="repmgr-standby-switchover">repmgr standby switchover</link></command>
|
|
log messages and provide new exit code <literal>ERR_SWITCHOVER_INCOMPLETE</literal> when old primary could
|
|
not be shut down cleanly
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
add check to verify the demotion candidate can make a replication connection to the
|
|
promotion candidate before executing a switchover (GitHub #370)
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
add check for sufficient walsenders and replication slots on the promotion candidate before executing
|
|
<command><link linkend="repmgr-standby-switchover">repmgr standby switchover</link></command>
|
|
(GitHub #371)
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
add --dry-run mode to <command><link linkend="repmgr-standby-switchover">repmgr standby follow</link></command>
|
|
(GitHub #368)
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
provide information about the primary node for
|
|
<command><link linkend="repmgr-standby-register">repmgr standby register</link></command> and
|
|
<command><link linkend="repmgr-standby-follow">repmgr standby follow</link></command> event notifications (GitHub #375)
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
add <literal>standby_register_sync</literal> <link linkend="event-notifications">event notification</link>, which is fired when
|
|
<command><link linkend="repmgr-standby-register">repmgr standby register</link></command>
|
|
is run with the <option>--wait-sync</option> option and the new or updated standby node
|
|
record has synchronised to the standby (GitHub #374)
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
when running <command><link linkend="repmgr-cluster-show">repmgr cluster show</link></command>,
|
|
if any node is unreachable, output the error message encountered in the list of warnings
|
|
(GitHub #369)
|
|
</para>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Bug fixes</title>
|
|
|
|
<para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
ensure an inactive data directory can be overwritten when
|
|
cloning a standby (GitHub #366)
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<command><link linkend="repmgr-node-status">repmgr node status</link></command>
|
|
upstream node display fixed (GitHub #363)
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<command><link linkend="repmgr-primary-unregister">repmgr primary unregister</link></command>:
|
|
clarify usage and fix <literal>--help</literal> output (GitHub #373)
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
parsing of <varname>pg_basebackup_options</varname> fixed (GitHub #376)
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
ensure the <filename>pg_subtrans</filename> directory is created when cloning a
|
|
standby in Barman mode
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<command><link linkend="repmgr-witness-register">repmgr witness register</link></command>:
|
|
fix primary node check (GitHub #377).
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
|
|
</para>
|
|
</sect2>
|
|
|
|
</sect1>
|
|
|
|
|
|
<sect1 id="release-4.0.2">
|
|
<title>Release 4.0.2</title>
|
|
<para><emphasis>Thu Jan 18, 2018</emphasis></para>
|
|
|
|
<para>
|
|
&repmgr; 4.0.2 contains some bug fixes and small usability enhancements.
|
|
</para>
|
|
<para>
|
|
This release can be installed as a simple package upgrade from &repmgr; 4.0.1 or 4.0;
|
|
&repmgrd; (if running) should be restarted.
|
|
</para>
|
|
|
|
<sect2>
|
|
<title>Usability enhancements</title>
|
|
|
|
<para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
Recognize the <option>-t</option>/<option>--terse</option> option for
|
|
<command><link linkend="repmgr-cluster-event">repmgr cluster event</link></command> to hide
|
|
the <literal>Details</literal> column (GitHub #360)
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
Add "--wait-start" option for
|
|
<command><link linkend="repmgr-standby-register">repmgr standby register</link></command>
|
|
(GitHub #356)
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
Add <literal>%p</literal> <link linkend="event-notifications">event notification parameter</link>
|
|
for <command><link linkend="repmgr-standby-switchover">repmgr standby switchover</link></command>
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Bug fixes</title>
|
|
|
|
<para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
Add missing -W option to <literal>getopt_long()</literal> invocation (GitHub #350)
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
Automatically create slot name if missing (GitHub #343)
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
Fixes to parsing output of remote repmgr invocations (GitHub #349)
|
|
</para>
|
|
</listitem>
|
|
|
|
|
|
<listitem>
|
|
<para>
|
|
When registering BDR nodes, automatically create missing connection replication set (GitHub #347)
|
|
</para>
|
|
</listitem>
|
|
|
|
|
|
<listitem>
|
|
<para>
|
|
Handle missing node record in <command><link linkend="repmgr-node-rejoin">repmgr node rejoin</link></command>
|
|
(GitHub #358)
|
|
</para>
|
|
</listitem>
|
|
|
|
|
|
</itemizedlist>
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Documentation</title>
|
|
|
|
<para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
The documentation can now be built as a single HTML file (GitHub pull request #353)
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</para>
|
|
</sect2>
|
|
|
|
</sect1>
|
|
|
|
<sect1 id="release-4.0.1">
|
|
<title>Release 4.0.1</title>
|
|
|
|
<para><emphasis>Wed Dec 13, 2017</emphasis></para>
|
|
|
|
<para>
|
|
&repmgr; 4.0.1 is a bugfix release.
|
|
</para>
|
|
<sect2>
|
|
<title>Bug fixes</title>
|
|
<para>
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
ensure correct return codes are returned for
|
|
<command><link linkend="repmgr-node-check">repmgr node check --action=</link></command> operations
|
|
(GitHub #340)
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
Fix <xref linkend="repmgr-cluster-show"/> when <literal>repmgr</literal> schema not set in search path
|
|
(GitHub #341)
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
When using <literal>--force-rewind</literal> with <xref linkend="repmgr-node-rejoin"/>
|
|
delete any replication slots copied by <application>pg_rewind</application>
|
|
(GitHub #334)
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
Only perform sanity check on accessibility of configuration files outside
|
|
the data directory when <literal>--copy-external-config-files</literal>
|
|
provided (GitHub #342)
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
Initialise "voting_term" table in application, not extension SQL
|
|
(GitHub #344)
|
|
</para>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
</para>
|
|
</sect2>
|
|
</sect1>
|
|
|
|
|
|
|
|
<sect1 id="release-4.0.0">
|
|
<title>Release 4.0.0</title>
|
|
|
|
<para><emphasis>Tue Nov 21, 2017</emphasis></para>
|
|
|
|
<para>
|
|
repmgr 4.0 is an entirely new version of &repmgr;, implementing &repmgr;
|
|
as a native PostgreSQL extension, adding new and improving existing features,
|
|
and making &repmgr; more user-friendly and intuitive to use. The new code base
|
|
will make it easier to add additional functionality for future releases.
|
|
</para>
|
|
<note>
|
|
<simpara>
|
|
With the new version, the opportunity has been taken to
|
|
make some changes in the way &repmgr; is set up and
|
|
configured. In particular changes have been made to some
|
|
configuration file settings consistency for and clarity.
|
|
Changes are covered in detail below
|
|
</simpara>
|
|
<simpara>
|
|
To standardise terminology, from this release <literal>primary</literal> is used to
|
|
denote the read/write node in a streaming replication cluster. <literal>master</literal>
|
|
is still accepted as an alias for &repmgr; commands
|
|
(e.g. <link linkend="repmgr-primary-register"><command>repmgr master register</command></link>).
|
|
</simpara>
|
|
</note>
|
|
|
|
<para>
|
|
For detailed instructions on upgrading from repmgr 3.x, see <xref linkend="upgrading-from-repmgr-3"/>.
|
|
</para>
|
|
|
|
<sect2>
|
|
<title>Features and improvements</title>
|
|
<para>
|
|
|
|
<itemizedlist>
|
|
<listitem>
|
|
<para>
|
|
<emphasis>improved switchover</emphasis>:
|
|
the <command>switchover</command> process has been improved and streamlined,
|
|
speeding up the switchover process and can also instruct other standbys
|
|
to follow the new primary once the switchover has completed. See
|
|
<xref linkend="performing-switchover"/> for more details.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<emphasis>"--dry-run" option</emphasis>: many &repmgr; commands now provide
|
|
a <literal>--dry-run</literal> option which will execute the command as far
|
|
as possible without making any changes, which will enable possible issues
|
|
to be identified before the intended operation is actually carried out.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<emphasis>easier upgrades</emphasis>: &repmgr; is now implemented as a native
|
|
PostgreSQL extension, which means future upgrades can be carried out by
|
|
installing the upgraded package and issuing
|
|
<ulink url="https://www.postgresql.org/docs/current/sql-alterextension.html">ALTER EXTENSION repmgr UPDATE</ulink>.
|
|
</para>
|
|
</listitem>
|
|
|
|
|
|
<listitem>
|
|
<para>
|
|
<emphasis>improved logging output</emphasis>:
|
|
&repmgr; (and &repmgrd;) now provide more explicit
|
|
logging output giving a better picture of what is going on. Where appropriate,
|
|
<literal>DETAIL</literal> and <literal>HINT</literal> log lines provide additional
|
|
detail and suggestions for resolving problems. Additionally, &repmgrd;
|
|
now emits informational log lines at regular, configurable intervals
|
|
to confirm that it's running correctly and which node(s) it's monitoring.
|
|
</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<emphasis>automatic configuration file location in packages</emphasis>:
|
|
Many operating system packages place the &repmgr; configuration files
|
|
in a version-specific subdirectory, e.g. <filename>/etc/repmgr/9.6/repmgr.conf</filename>;
|
|
&repmgr; now makes it easy for package maintainers to provide a patch
|
|
with the actual file location, meaning <filename>repmgr.conf</filename>
|
|
does not need to be provided explicitly. This is currently the case
|
|
for 2ndQuadrant-provided <literal>.deb</literal> and <literal>.rpm</literal> packages.
|
|
</para>
|
|
</listitem>
|
|
|
|
|
|
<listitem>
|
|
<para>
|
|
<emphasis>monitoring and status checks</emphasis>:
|
|
New commands <xref linkend="repmgr-node-check"/> and
|
|
<xref linkend="repmgr-node-status"/> providing information
|
|
about a node's status and replication-related monitoring
|
|
output.
|
|
</para>
|
|
</listitem>
|
|
|
|
|
|
<listitem>
|
|
<para>
|
|
<emphasis>node rejoin</emphasis>:
|
|
New commands <xref linkend="repmgr-node-rejoin"/> enables a failed
|
|
primary to be rejoined to a replication cluster, optionally using
|
|
<application>pg_rewind</application> to synchronise its data,
|
|
(note that <application>pg_rewind</application> may not be useable
|
|
in some circumstances).
|
|
</para>
|
|
</listitem>
|
|
|
|
|
|
<listitem>
|
|
<para>
|
|
<emphasis>automatic failover</emphasis>:
|
|
improved detection of node status; promotion decision based on a consensual
|
|
model, with the promoted primary explicitly informing other standbys to
|
|
follow it. The &repmgrd; daemon will continue
|
|
functioning even if the monitored PostgreSQL instance is down, and resume
|
|
monitoring if it reappears. Additionally, if the instance's role has changed
|
|
(typically from a primary to a standby, e.g. following reintegration of a
|
|
failed primary using <xref linkend="repmgr-node-rejoin"/>) &repmgrd;
|
|
will automatically resume monitoring it as a standby.
|
|
</para>
|
|
</listitem>
|
|
|
|
|
|
|
|
<listitem>
|
|
<para>
|
|
<emphasis>new documentation</emphasis>:
|
|
the existing documentation spread over multiple text files
|
|
has been consolidated into DocBook format (as used by the
|
|
main PostgreSQL project) and is now available online in
|
|
HTML format.
|
|
</para>
|
|
<para>
|
|
The DocBook files can easily be used to create versions
|
|
of the documentation in other formats such as PDF.
|
|
</para>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
|
|
</para>
|
|
</sect2>
|
|
<sect2>
|
|
<title>New command line options</title>
|
|
<para>
|
|
<itemizedlist>
|
|
|
|
<listitem><para>
|
|
<literal>--dry-run</literal>: &repmgr; will attempt to perform
|
|
the action as far as possible without making any changes to the
|
|
database
|
|
</para></listitem>
|
|
|
|
<listitem>
|
|
<para>
|
|
<literal>--upstream-node-id</literal>: use to specify the upstream node
|
|
the standby will connect later stream from, when <link linkend="repmgr-standby-clone">cloning</link>
|
|
and <link linkend="repmgr-standby-register">registering</link> a standby.
|
|
</para>
|
|
<para>
|
|
This replaces the configuration file parameter <varname>upstream_node</varname>.
|
|
as the upstream node is set when the standby is initially cloned, but can change
|
|
over the lifetime of an installation (due to failovers, switchovers etc.) so it's
|
|
pointless/confusing keeping the original value around in <filename>repmgr.conf</filename>.
|
|
</para></listitem>
|
|
|
|
</itemizedlist>
|
|
</para>
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Changed command line options</title>
|
|
<para>
|
|
<application>repmgr</application>
|
|
<itemizedlist>
|
|
|
|
<listitem><para>
|
|
<literal>--replication-user</literal> has been deprecated; it has been replaced
|
|
by the configuration file option <varname>replication_user</varname>.
|
|
The value (which defaults to the user provided in the <varname>conninfo</varname>
|
|
string) will be stored in the &repmgr; metadata for use by
|
|
<xref linkend="repmgr-standby-clone"/> and <xref linkend="repmgr-standby-follow"/>.
|
|
</para></listitem>
|
|
|
|
<listitem><para>
|
|
<literal>--recovery-min-apply-delay</literal> is now a configuration file parameter
|
|
<varname>recovery_min_apply_delay</varname>, to ensure the setting does not get lost
|
|
when a standby follows a new upstream.
|
|
</para></listitem>
|
|
|
|
<listitem><para>
|
|
<literal>--no-conninfo-password</literal> is deprecated; a password included in
|
|
the environment variable <varname>PGPASSWORD</varname> will no longer be added
|
|
to <varname>primary_conninfo</varname> by default; to force the inclusion
|
|
of a password (not recommended), use the new configuration file parameter
|
|
<varname>use_primary_conninfo_password</varname>. For details, ee section
|
|
<xref linkend="cloning-advanced-managing-passwords"/>.
|
|
</para></listitem>
|
|
|
|
</itemizedlist>
|
|
</para>
|
|
|
|
<para>
|
|
&repmgrd;
|
|
<itemizedlist>
|
|
|
|
<listitem><para>
|
|
<literal>--monitoring-history</literal> is deprecated and is replaced by the
|
|
configuration file option <varname>monitoring_history</varname>.
|
|
This enables the setting to be changed without having to modify system service
|
|
files.
|
|
</para></listitem>
|
|
|
|
</itemizedlist>
|
|
</para>
|
|
|
|
</sect2>
|
|
|
|
<sect2>
|
|
<title>Configuration file changes</title>
|
|
|
|
<para><emphasis>Required settings</emphasis></para>
|
|
<para>The following 4 parameters are mandatory in <filename>repmgr.conf</filename>:
|
|
<itemizedlist spacing="compact" mark="bullet">
|
|
|
|
<listitem>
|
|
<simpara>node_id</simpara>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<simpara>node_name</simpara>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<simpara>conninfo</simpara>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<simpara>data_directory</simpara>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</para>
|
|
|
|
<para><emphasis>Renamed settings</emphasis></para>
|
|
<para>
|
|
Some settings have been renamed for clarity and consistency:
|
|
<itemizedlist spacing="compact" mark="bullet">
|
|
|
|
<listitem>
|
|
<simpara><varname>node</varname> is now <varname>node_id</varname></simpara>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<simpara><varname>name</varname> is now <varname>node_name</varname></simpara>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<simpara><varname>barman_server</varname> is now <varname>barman_host</varname></simpara>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<simpara><varname>master_reponse_timeout</varname> is now
|
|
<varname>async_query_timeout</varname> (to better indicate its purpose)
|
|
</simpara>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
</para>
|
|
|
|
<para>
|
|
The following configuration file parameters have been renamed for consistency
|
|
with other parameters (and conform to the pattern used by PostgreSQL itself,
|
|
which uses the prefix <varname>log_</varname> for logging parameters):
|
|
|
|
<itemizedlist spacing="compact" mark="bullet">
|
|
|
|
<listitem>
|
|
<simpara><varname>loglevel</varname> is now <varname>log_level</varname></simpara>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<simpara><varname>logfile</varname> is now <varname>log_file</varname></simpara>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<simpara><varname>logfacility</varname> is now <varname>log_facility</varname></simpara>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
</para>
|
|
|
|
<para><emphasis>Removed settings</emphasis></para>
|
|
<para>
|
|
<itemizedlist spacing="compact" mark="bullet">
|
|
|
|
<listitem>
|
|
<simpara><varname>cluster</varname> has been removed</simpara>
|
|
</listitem>
|
|
<listitem>
|
|
<simpara><varname>upstream_node</varname> - see note about
|
|
<literal>--upstream-node-id</literal> above</simpara>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<simpara><varname>retry_promote_interval_secs</varname>this is now redundant due
|
|
to changes in the failover/promotion mechanism; the new equivalent is
|
|
<varname>primary_notification_timeout</varname> </simpara>
|
|
</listitem>
|
|
</itemizedlist>
|
|
</para>
|
|
|
|
<para><emphasis>Logging changes</emphasis></para>
|
|
<para>
|
|
<itemizedlist spacing="compact" mark="bullet">
|
|
|
|
<listitem>
|
|
<simpara>
|
|
default value for <varname>log_level</varname> is <literal>INFO</literal>
|
|
rather than <literal>NOTICE</literal>.
|
|
</simpara>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<simpara>
|
|
new parameter <varname>log_status_interval</varname>, which causes
|
|
&repmgrd; to emit a status log
|
|
line at the specified interval
|
|
</simpara>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
|
|
</para>
|
|
|
|
</sect2>
|
|
<sect2>
|
|
<title>repmgrd</title>
|
|
<para>
|
|
The shared library has been renamed from <literal>repmgr_funcs</literal> to
|
|
<literal>repmgr</literal>, meaning <varname>shared_preload_libraries</varname>
|
|
in <filename>postgresql.conf</filename> needs to be updated to the new name:
|
|
<programlisting>
|
|
shared_preload_libraries = 'repmgr'</programlisting>
|
|
</para>
|
|
</sect2>
|
|
|
|
</sect1>
|
|
|
|
</appendix>
|