Files
repmgr/doc/appendix-release-notes.sgml
2017-11-23 10:34:21 +09:00

407 lines
14 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>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>
</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>