mirror of
https://github.com/EnterpriseDB/repmgr.git
synced 2026-03-23 15:16:29 +00:00
430 lines
15 KiB
Plaintext
430 lines
15 KiB
Plaintext
<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>
|
|
|
|
<sect1 id="release-4.0.1">
|
|
<title>Release 4.0.1</title>
|
|
|
|
<para><emphasis>Mon Dec 4, 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/static/sql-alterextension.html">ALTER EXTENSION repmgr UPDATE</ulink>.
|
|
</para>
|
|
</listitem>
|
|
|
|
|
|
<listitem>
|
|
<para>
|
|
<emphasis>improved logging output</emphasis>:
|
|
&repmgr; (and <application>repmgrd</application>) 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, <application>repmgrd</application>
|
|
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 <application>repmgrd</application> 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">) <application>repmgrd</application>
|
|
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>
|
|
<application>repmgrd</application>
|
|
<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
|
|
<application>repmgrd</application> to emit a status log
|
|
line at the specified interval
|
|
</simpara>
|
|
</listitem>
|
|
|
|
</itemizedlist>
|
|
|
|
</para>
|
|
|
|
</sect2>
|
|
<sect2>
|
|
<title>repmgrd</title>
|
|
<para>
|
|
The `repmgr` 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>
|