2010-09-20 22:08:53 +02:00
|
|
|
<!-- doc/src/sgml/recovery-config.sgml -->
|
2010-02-22 12:47:30 +01:00
|
|
|
|
2011-04-05 20:06:06 +02:00
|
|
|
<chapter id="recovery-config">
|
2010-02-22 12:47:30 +01:00
|
|
|
<title>Recovery Configuration</title>
|
|
|
|
|
|
|
|
<indexterm>
|
|
|
|
<primary>configuration</primary>
|
|
|
|
<secondary>of recovery</secondary>
|
|
|
|
<tertiary>of a standby server</tertiary>
|
|
|
|
</indexterm>
|
|
|
|
|
|
|
|
<para>
|
2010-04-21 05:32:53 +02:00
|
|
|
This chapter describes the settings available in the
|
2011-08-23 10:55:21 +02:00
|
|
|
<filename>recovery.conf</><indexterm><primary>recovery.conf</></>
|
|
|
|
file. They apply only for the duration of the
|
2010-04-21 05:32:53 +02:00
|
|
|
recovery. They must be reset for any subsequent recovery you wish to
|
|
|
|
perform. They cannot be changed once recovery has begun.
|
2010-02-22 12:47:30 +01:00
|
|
|
</para>
|
|
|
|
|
2010-04-07 12:58:49 +02:00
|
|
|
<para>
|
|
|
|
Settings in <filename>recovery.conf</> are specified in the format
|
|
|
|
<literal>name = 'value'</>. One parameter is specified per line.
|
|
|
|
Hash marks (<literal>#</literal>) designate the rest of the
|
|
|
|
line as a comment. To embed a single quote in a parameter
|
|
|
|
value, write two quotes (<literal>''</>).
|
|
|
|
</para>
|
|
|
|
|
2010-04-21 05:32:53 +02:00
|
|
|
<para>
|
|
|
|
A sample file, <filename>share/recovery.conf.sample</>,
|
|
|
|
is provided in the installation's <filename>share/</> directory.
|
|
|
|
</para>
|
|
|
|
|
2010-02-22 12:47:30 +01:00
|
|
|
<sect1 id="archive-recovery-settings">
|
|
|
|
|
2011-01-29 19:00:18 +01:00
|
|
|
<title>Archive Recovery Settings</title>
|
2010-02-22 12:47:30 +01:00
|
|
|
<variablelist>
|
|
|
|
|
|
|
|
<varlistentry id="restore-command" xreflabel="restore_command">
|
|
|
|
<term><varname>restore_command</varname> (<type>string</type>)</term>
|
2010-04-28 09:34:11 +02:00
|
|
|
<indexterm>
|
|
|
|
<primary><varname>restore_command</> recovery parameter</primary>
|
|
|
|
</indexterm>
|
2010-02-22 12:47:30 +01:00
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
The shell command to execute to retrieve an archived segment of
|
|
|
|
the WAL file series. This parameter is required for archive recovery,
|
|
|
|
but optional for streaming replication.
|
|
|
|
Any <literal>%f</> in the string is
|
|
|
|
replaced by the name of the file to retrieve from the archive,
|
|
|
|
and any <literal>%p</> is replaced by the copy destination path name
|
|
|
|
on the server.
|
|
|
|
(The path name is relative to the current working directory,
|
|
|
|
i.e., the cluster's data directory.)
|
|
|
|
Any <literal>%r</> is replaced by the name of the file containing the
|
|
|
|
last valid restart point. That is the earliest file that must be kept
|
|
|
|
to allow a restore to be restartable, so this information can be used
|
|
|
|
to truncate the archive to just the minimum required to support
|
|
|
|
restarting from the current restore. <literal>%r</> is typically only
|
|
|
|
used by warm-standby configurations
|
|
|
|
(see <xref linkend="warm-standby">).
|
|
|
|
Write <literal>%%</> to embed an actual <literal>%</> character.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>
|
|
|
|
It is important for the command to return a zero exit status
|
|
|
|
only if it succeeds. The command <emphasis>will</> be asked for file
|
|
|
|
names that are not present in the archive; it must return nonzero
|
|
|
|
when so asked. Examples:
|
|
|
|
<programlisting>
|
|
|
|
restore_command = 'cp /mnt/server/archivedir/%f "%p"'
|
|
|
|
restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"' # Windows
|
|
|
|
</programlisting>
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
2010-06-10 10:13:50 +02:00
|
|
|
<varlistentry id="archive-cleanup-command" xreflabel="archive_cleanup_command">
|
|
|
|
<term><varname>archive_cleanup_command</varname> (<type>string</type>)</term>
|
2010-04-28 09:34:11 +02:00
|
|
|
<indexterm>
|
2010-06-10 10:13:50 +02:00
|
|
|
<primary><varname>archive_cleanup_command</> recovery parameter</primary>
|
2010-04-28 09:34:11 +02:00
|
|
|
</indexterm>
|
2010-02-22 12:47:30 +01:00
|
|
|
<listitem>
|
|
|
|
<para>
|
2010-10-14 20:30:15 +02:00
|
|
|
This optional parameter specifies a shell command that will be executed
|
|
|
|
at every restartpoint. The purpose of
|
|
|
|
<varname>archive_cleanup_command</> is to provide a mechanism for
|
|
|
|
cleaning up old archived WAL files that are no longer needed by the
|
|
|
|
standby server.
|
|
|
|
Any <literal>%r</> is replaced by the name of the file containing the
|
|
|
|
last valid restart point.
|
|
|
|
That is the earliest file that must be <emphasis>kept</> to allow a
|
|
|
|
restore to be restartable, and so all files earlier than <literal>%r</>
|
|
|
|
may be safely removed.
|
|
|
|
This information can be used to truncate the archive to just the
|
|
|
|
minimum required to support restart from the current restore.
|
2011-01-26 15:22:21 +01:00
|
|
|
The <xref linkend="pgarchivecleanup"> module
|
|
|
|
is often used in <varname>archive_cleanup_command</> for
|
2010-10-14 20:30:15 +02:00
|
|
|
single-standby configurations, for example:
|
2011-05-02 18:19:48 +02:00
|
|
|
<programlisting>archive_cleanup_command = 'pg_archivecleanup /mnt/server/archivedir %r'</programlisting>
|
2010-10-14 20:30:15 +02:00
|
|
|
Note however that if multiple standby servers are restoring from the
|
|
|
|
same archive directory, you will need to ensure that you do not delete
|
|
|
|
WAL files until they are no longer needed by any of the servers.
|
|
|
|
<varname>archive_cleanup_command</> would typically be used in a
|
|
|
|
warm-standby configuration (see <xref linkend="warm-standby">).
|
|
|
|
Write <literal>%%</> to embed an actual <literal>%</> character in the
|
|
|
|
command.
|
2010-02-22 12:47:30 +01:00
|
|
|
</para>
|
2010-03-18 10:17:18 +01:00
|
|
|
<para>
|
|
|
|
If the command returns a non-zero exit status then a WARNING log
|
|
|
|
message will be written.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
<varlistentry id="recovery-end-command" xreflabel="recovery_end_command">
|
|
|
|
<term><varname>recovery_end_command</varname> (<type>string</type>)</term>
|
2010-04-28 09:34:11 +02:00
|
|
|
<indexterm>
|
|
|
|
<primary><varname>recovery_end_command</> recovery parameter</primary>
|
|
|
|
</indexterm>
|
2010-03-18 10:17:18 +01:00
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
This parameter specifies a shell command that will be executed once only
|
|
|
|
at the end of recovery. This parameter is optional. The purpose of the
|
|
|
|
<varname>recovery_end_command</> is to provide a mechanism for cleanup
|
|
|
|
following replication or recovery.
|
|
|
|
Any <literal>%r</> is replaced by the name of the file containing the
|
2010-06-10 10:13:50 +02:00
|
|
|
last valid restart point, like in <xref linkend="archive-cleanup-command">.
|
2010-03-18 10:17:18 +01:00
|
|
|
</para>
|
2010-02-22 12:47:30 +01:00
|
|
|
<para>
|
|
|
|
If the command returns a non-zero exit status then a WARNING log
|
|
|
|
message will be written and the database will proceed to start up
|
|
|
|
anyway. An exception is that if the command was terminated by a
|
|
|
|
signal, the database will not proceed with startup.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
</variablelist>
|
|
|
|
|
|
|
|
</sect1>
|
|
|
|
|
|
|
|
<sect1 id="recovery-target-settings">
|
|
|
|
|
2011-01-29 19:00:18 +01:00
|
|
|
<title>Recovery Target Settings</title>
|
2010-02-22 12:47:30 +01:00
|
|
|
<variablelist>
|
|
|
|
|
2011-02-08 20:39:08 +01:00
|
|
|
<varlistentry id="recovery-target-name" xreflabel="recovery_target_name">
|
|
|
|
<term><varname>recovery_target_name</varname>
|
|
|
|
(<type>string</type>)
|
|
|
|
</term>
|
|
|
|
<indexterm>
|
|
|
|
<primary><varname>recovery_target_name</> recovery parameter</primary>
|
|
|
|
</indexterm>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
2011-02-09 14:15:38 +01:00
|
|
|
This parameter specifies the named restore point, created with
|
|
|
|
<function>pg_create_restore_point()</> to which recovery will proceed.
|
|
|
|
At most one of <varname>recovery_target_name</>,
|
|
|
|
<xref linkend="recovery-target-time"> or
|
|
|
|
<xref linkend="recovery-target-xid"> can be specified. The default is to
|
|
|
|
recover to the end of the WAL log.
|
2011-02-08 20:39:08 +01:00
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
2010-02-22 12:47:30 +01:00
|
|
|
<varlistentry id="recovery-target-time" xreflabel="recovery_target_time">
|
|
|
|
<term><varname>recovery_target_time</varname>
|
|
|
|
(<type>timestamp</type>)
|
|
|
|
</term>
|
2010-04-28 09:34:11 +02:00
|
|
|
<indexterm>
|
|
|
|
<primary><varname>recovery_target_time</> recovery parameter</primary>
|
|
|
|
</indexterm>
|
2010-02-22 12:47:30 +01:00
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
This parameter specifies the time stamp up to which recovery
|
|
|
|
will proceed.
|
2011-02-08 20:39:08 +01:00
|
|
|
At most one of <varname>recovery_target_time</>,
|
2011-02-09 14:16:49 +01:00
|
|
|
<xref linkend="recovery-target-name"> or
|
2010-02-22 12:47:30 +01:00
|
|
|
<xref linkend="recovery-target-xid"> can be specified.
|
|
|
|
The default is to recover to the end of the WAL log.
|
|
|
|
The precise stopping point is also influenced by
|
|
|
|
<xref linkend="recovery-target-inclusive">.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
<varlistentry id="recovery-target-xid" xreflabel="recovery_target_xid">
|
|
|
|
<term><varname>recovery_target_xid</varname> (<type>string</type>)</term>
|
2010-04-28 09:34:11 +02:00
|
|
|
<indexterm>
|
|
|
|
<primary><varname>recovery_target_xid</> recovery parameter</primary>
|
|
|
|
</indexterm>
|
2010-02-22 12:47:30 +01:00
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
This parameter specifies the transaction ID up to which recovery
|
|
|
|
will proceed. Keep in mind
|
|
|
|
that while transaction IDs are assigned sequentially at transaction
|
|
|
|
start, transactions can complete in a different numeric order.
|
|
|
|
The transactions that will be recovered are those that committed
|
|
|
|
before (and optionally including) the specified one.
|
2011-02-08 20:39:08 +01:00
|
|
|
At most one of <varname>recovery_target_xid</>,
|
2011-02-09 14:16:49 +01:00
|
|
|
<xref linkend="recovery-target-name"> or
|
2010-02-22 12:47:30 +01:00
|
|
|
<xref linkend="recovery-target-time"> can be specified.
|
|
|
|
The default is to recover to the end of the WAL log.
|
|
|
|
The precise stopping point is also influenced by
|
|
|
|
<xref linkend="recovery-target-inclusive">.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
<varlistentry id="recovery-target-inclusive"
|
|
|
|
xreflabel="recovery_target_inclusive">
|
|
|
|
<term><varname>recovery_target_inclusive</varname>
|
|
|
|
(<type>boolean</type>)
|
|
|
|
</term>
|
2010-04-28 09:34:11 +02:00
|
|
|
<indexterm>
|
|
|
|
<primary><varname>recovery_target_inclusive</> recovery parameter</primary>
|
|
|
|
</indexterm>
|
2010-02-22 12:47:30 +01:00
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
Specifies whether we stop just after the specified recovery target
|
|
|
|
(<literal>true</literal>), or just before the recovery target
|
|
|
|
(<literal>false</literal>).
|
|
|
|
Applies to both <xref linkend="recovery-target-time">
|
|
|
|
and <xref linkend="recovery-target-xid">, whichever one is
|
|
|
|
specified for this recovery. This indicates whether transactions
|
|
|
|
having exactly the target commit time or ID, respectively, will
|
|
|
|
be included in the recovery. Default is <literal>true</>.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
<varlistentry id="recovery-target-timeline"
|
|
|
|
xreflabel="recovery_target_timeline">
|
|
|
|
<term><varname>recovery_target_timeline</varname>
|
|
|
|
(<type>string</type>)
|
|
|
|
</term>
|
2010-04-28 09:34:11 +02:00
|
|
|
<indexterm>
|
|
|
|
<primary><varname>recovery_target_timeline</> recovery parameter</primary>
|
|
|
|
</indexterm>
|
2010-02-22 12:47:30 +01:00
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
Specifies recovering into a particular timeline. The default is
|
|
|
|
to recover along the same timeline that was current when the
|
2011-03-07 20:02:40 +01:00
|
|
|
base backup was taken. Setting this to <literal>latest</> recovers
|
|
|
|
to the latest timeline found in the archive, which is useful in
|
|
|
|
a standby server. Other than that you only need to set this parameter
|
2010-02-22 12:47:30 +01:00
|
|
|
in complex re-recovery situations, where you need to return to
|
|
|
|
a state that itself was reached after a point-in-time recovery.
|
|
|
|
See <xref linkend="backup-timelines"> for discussion.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
2011-02-08 19:30:22 +01:00
|
|
|
<varlistentry id="pause-at-recovery-target"
|
|
|
|
xreflabel="pause_at_recovery_target">
|
|
|
|
<term><varname>pause_at_recovery_target</varname>
|
|
|
|
(<type>boolean</type>)
|
|
|
|
</term>
|
|
|
|
<indexterm>
|
|
|
|
<primary><varname>pause_at_recovery_target</> recovery parameter</primary>
|
|
|
|
</indexterm>
|
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
Specifies whether recovery should pause when the recovery target
|
2011-03-17 19:02:41 +01:00
|
|
|
is reached. The default is true.
|
2011-02-08 19:30:22 +01:00
|
|
|
This is intended to allow queries to be executed against the
|
|
|
|
database to check if this recovery target is the most desirable
|
|
|
|
point for recovery. The paused state can be resumed by using
|
|
|
|
<function>pg_xlog_replay_resume()</> (See
|
|
|
|
<xref linkend="functions-recovery-control-table">), which then
|
|
|
|
causes recovery to end. If this recovery target is not the
|
|
|
|
desired stopping point, then shutdown the server, change the
|
|
|
|
recovery target settings to a later target and restart to
|
|
|
|
continue recovery.
|
|
|
|
</para>
|
2011-03-17 19:02:41 +01:00
|
|
|
<para>
|
|
|
|
This setting has no effect if <xref linkend="guc-hot-standby"> is not
|
|
|
|
enabled, or if no recovery target is set.
|
|
|
|
</para>
|
2011-02-08 19:30:22 +01:00
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
2010-02-22 12:47:30 +01:00
|
|
|
</variablelist>
|
|
|
|
</sect1>
|
|
|
|
|
|
|
|
<sect1 id="standby-settings">
|
|
|
|
|
2011-01-29 19:00:18 +01:00
|
|
|
<title>Standby Server Settings</title>
|
2010-02-22 12:47:30 +01:00
|
|
|
<variablelist>
|
|
|
|
|
|
|
|
<varlistentry id="standby-mode" xreflabel="standby_mode">
|
|
|
|
<term><varname>standby_mode</varname> (<type>boolean</type>)</term>
|
2010-04-28 09:34:11 +02:00
|
|
|
<indexterm>
|
|
|
|
<primary><varname>standby_mode</> recovery parameter</primary>
|
|
|
|
</indexterm>
|
2010-02-22 12:47:30 +01:00
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
Specifies whether to start the <productname>PostgreSQL</> server as
|
|
|
|
a standby. If this parameter is <literal>on</>, the server will
|
2010-04-21 05:32:53 +02:00
|
|
|
not stop recovery when the end of archived WAL is reached, but
|
|
|
|
will keep trying to continue recovery by fetching new WAL segments
|
|
|
|
using <varname>restore_command</>
|
|
|
|
and/or by connecting to the primary server as specified by the
|
2010-02-22 12:47:30 +01:00
|
|
|
<varname>primary_conninfo</> setting.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
<varlistentry id="primary-conninfo" xreflabel="primary_conninfo">
|
|
|
|
<term><varname>primary_conninfo</varname> (<type>string</type>)</term>
|
2010-04-28 09:34:11 +02:00
|
|
|
<indexterm>
|
|
|
|
<primary><varname>primary_conninfo</> recovery parameter</primary>
|
|
|
|
</indexterm>
|
2010-02-22 12:47:30 +01:00
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
Specifies a connection string to be used for the standby server
|
2010-02-25 10:32:19 +01:00
|
|
|
to connect with the primary. This string is in the format
|
|
|
|
accepted by the libpq <function>PQconnectdb</function> function,
|
2010-02-22 12:47:30 +01:00
|
|
|
described in <xref linkend="libpq-connect">. If any option is
|
|
|
|
unspecified in this string, then the corresponding environment
|
|
|
|
variable (see <xref linkend="libpq-envars">) is checked. If the
|
|
|
|
environment variable is not set either, then
|
|
|
|
defaults are used.
|
|
|
|
</para>
|
|
|
|
<para>
|
2010-04-21 05:32:53 +02:00
|
|
|
The connection string should specify the host name (or address)
|
|
|
|
of the primary server, as well as the port number if it is not
|
|
|
|
the same as the standby server's default.
|
|
|
|
Also specify a user name corresponding to a role that has the
|
2011-09-14 08:30:32 +02:00
|
|
|
<literal>REPLICATION</> and <literal>LOGIN</> privileges on the
|
2010-04-21 05:32:53 +02:00
|
|
|
primary (see
|
|
|
|
<xref linkend="streaming-replication-authentication">).
|
|
|
|
A password needs to be provided too, if the primary demands password
|
2010-06-11 12:13:09 +02:00
|
|
|
authentication. It can be provided in the
|
|
|
|
<varname>primary_conninfo</varname> string, or in a separate
|
|
|
|
<filename>~/.pgpass</> file on the standby server (use
|
|
|
|
<literal>replication</> as the database name).
|
2010-04-21 05:32:53 +02:00
|
|
|
Do not specify a database name in the
|
|
|
|
<varname>primary_conninfo</varname> string.
|
2010-02-22 12:47:30 +01:00
|
|
|
</para>
|
|
|
|
<para>
|
|
|
|
This setting has no effect if <varname>standby_mode</> is <literal>off</>.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
<varlistentry id="trigger-file" xreflabel="trigger_file">
|
|
|
|
<term><varname>trigger_file</varname> (<type>string</type>)</term>
|
2010-04-28 09:34:11 +02:00
|
|
|
<indexterm>
|
|
|
|
<primary><varname>trigger_file</> recovery parameter</primary>
|
|
|
|
</indexterm>
|
2010-02-22 12:47:30 +01:00
|
|
|
<listitem>
|
|
|
|
<para>
|
|
|
|
Specifies a trigger file whose presence ends recovery in the
|
2011-02-16 03:28:48 +01:00
|
|
|
standby. Even if this value is not set, you can still promote
|
|
|
|
the standby using <command>pg_ctl promote</>.
|
2010-02-22 12:47:30 +01:00
|
|
|
This setting has no effect if <varname>standby_mode</> is <literal>off</>.
|
|
|
|
</para>
|
|
|
|
</listitem>
|
|
|
|
</varlistentry>
|
|
|
|
|
|
|
|
</variablelist>
|
|
|
|
</sect1>
|
|
|
|
|
|
|
|
</chapter>
|