mirror of https://github.com/postgres/postgres
recovery.conf settings are now set in postgresql.conf (or other GUC sources). Currently, all the affected settings are PGC_POSTMASTER; this could be refined in the future case by case. Recovery is now initiated by a file recovery.signal. Standby mode is initiated by a file standby.signal. The standby_mode setting is gone. If a recovery.conf file is found, an error is issued. The trigger_file setting has been renamed to promote_trigger_file as part of the move. The documentation chapter "Recovery Configuration" has been integrated into "Server Configuration". pg_basebackup -R now appends settings to postgresql.auto.conf and creates a standby.signal file. Author: Fujii Masao <masao.fujii@gmail.com> Author: Simon Riggs <simon@2ndquadrant.com> Author: Abhijit Menon-Sen <ams@2ndquadrant.com> Author: Sergei Kornilov <sk@zsrv.org> Discussion: https://www.postgresql.org/message-id/flat/607741529606767@web3g.yandex.ru/pull/34/head
Peter Eisentraut
7 years ago
parent
ab69ea9fee
commit
2dedf4d9a8
@ -1,510 +0,0 @@ |
|||||||
<!-- doc/src/sgml/recovery-config.sgml --> |
|
||||||
|
|
||||||
<chapter id="recovery-config"> |
|
||||||
<title>Recovery Configuration</title> |
|
||||||
|
|
||||||
<indexterm> |
|
||||||
<primary>configuration</primary> |
|
||||||
<secondary>of recovery</secondary> |
|
||||||
<tertiary>of a standby server</tertiary> |
|
||||||
</indexterm> |
|
||||||
|
|
||||||
<para> |
|
||||||
This chapter describes the settings available in the |
|
||||||
<filename>recovery.conf</filename><indexterm><primary>recovery.conf</primary></indexterm> |
|
||||||
file. They apply only for the duration of the |
|
||||||
recovery. They must be reset for any subsequent recovery you wish to |
|
||||||
perform. They cannot be changed once recovery has begun. |
|
||||||
</para> |
|
||||||
|
|
||||||
<para> |
|
||||||
Settings in <filename>recovery.conf</filename> are specified in the format |
|
||||||
<literal>name = 'value'</literal>. 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>''</literal>). |
|
||||||
</para> |
|
||||||
|
|
||||||
<para> |
|
||||||
A sample file, <filename>share/recovery.conf.sample</filename>, |
|
||||||
is provided in the installation's <filename>share/</filename> directory. |
|
||||||
</para> |
|
||||||
|
|
||||||
<sect1 id="archive-recovery-settings"> |
|
||||||
|
|
||||||
<title>Archive Recovery Settings</title> |
|
||||||
<variablelist> |
|
||||||
|
|
||||||
<varlistentry id="restore-command" xreflabel="restore_command"> |
|
||||||
<term><varname>restore_command</varname> (<type>string</type>) |
|
||||||
<indexterm> |
|
||||||
<primary><varname>restore_command</varname> recovery parameter</primary> |
|
||||||
</indexterm> |
|
||||||
</term> |
|
||||||
<listitem> |
|
||||||
<para> |
|
||||||
The local 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</literal> in the string is |
|
||||||
replaced by the name of the file to retrieve from the archive, |
|
||||||
and any <literal>%p</literal> 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</literal> 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</literal> is typically only |
|
||||||
used by warm-standby configurations |
|
||||||
(see <xref linkend="warm-standby"/>). |
|
||||||
Write <literal>%%</literal> to embed an actual <literal>%</literal> character. |
|
||||||
</para> |
|
||||||
|
|
||||||
<para> |
|
||||||
It is important for the command to return a zero exit status |
|
||||||
only if it succeeds. The command <emphasis>will</emphasis> 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> |
|
||||||
An exception is that if the command was terminated by a signal (other |
|
||||||
than <systemitem>SIGTERM</systemitem>, which is used as part of a |
|
||||||
database server shutdown) or an error by the shell (such as command |
|
||||||
not found), then recovery will abort and the server will not start up. |
|
||||||
</para> |
|
||||||
</listitem> |
|
||||||
</varlistentry> |
|
||||||
|
|
||||||
<varlistentry id="archive-cleanup-command" xreflabel="archive_cleanup_command"> |
|
||||||
<term><varname>archive_cleanup_command</varname> (<type>string</type>) |
|
||||||
<indexterm> |
|
||||||
<primary><varname>archive_cleanup_command</varname> recovery parameter</primary> |
|
||||||
</indexterm> |
|
||||||
</term> |
|
||||||
<listitem> |
|
||||||
<para> |
|
||||||
This optional parameter specifies a shell command that will be executed |
|
||||||
at every restartpoint. The purpose of |
|
||||||
<varname>archive_cleanup_command</varname> is to provide a mechanism for |
|
||||||
cleaning up old archived WAL files that are no longer needed by the |
|
||||||
standby server. |
|
||||||
Any <literal>%r</literal> is replaced by the name of the file containing the |
|
||||||
last valid restart point. |
|
||||||
That is the earliest file that must be <emphasis>kept</emphasis> to allow a |
|
||||||
restore to be restartable, and so all files earlier than <literal>%r</literal> |
|
||||||
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. |
|
||||||
The <xref linkend="pgarchivecleanup"/> module |
|
||||||
is often used in <varname>archive_cleanup_command</varname> for |
|
||||||
single-standby configurations, for example: |
|
||||||
<programlisting>archive_cleanup_command = 'pg_archivecleanup /mnt/server/archivedir %r'</programlisting> |
|
||||||
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</varname> would typically be used in a |
|
||||||
warm-standby configuration (see <xref linkend="warm-standby"/>). |
|
||||||
Write <literal>%%</literal> to embed an actual <literal>%</literal> character in the |
|
||||||
command. |
|
||||||
</para> |
|
||||||
<para> |
|
||||||
If the command returns a nonzero exit status then a warning log |
|
||||||
message will be written. An exception is that if the command was |
|
||||||
terminated by a signal or an error by the shell (such as command not |
|
||||||
found), a fatal error will be raised. |
|
||||||
</para> |
|
||||||
</listitem> |
|
||||||
</varlistentry> |
|
||||||
|
|
||||||
<varlistentry id="recovery-end-command" xreflabel="recovery_end_command"> |
|
||||||
<term><varname>recovery_end_command</varname> (<type>string</type>) |
|
||||||
<indexterm> |
|
||||||
<primary><varname>recovery_end_command</varname> recovery parameter</primary> |
|
||||||
</indexterm> |
|
||||||
</term> |
|
||||||
<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</varname> is to provide a mechanism for cleanup |
|
||||||
following replication or recovery. |
|
||||||
Any <literal>%r</literal> is replaced by the name of the file containing the |
|
||||||
last valid restart point, like in <xref linkend="archive-cleanup-command"/>. |
|
||||||
</para> |
|
||||||
<para> |
|
||||||
If the command returns a nonzero 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 or an error by the shell (such as command not found), the |
|
||||||
database will not proceed with startup. |
|
||||||
</para> |
|
||||||
</listitem> |
|
||||||
</varlistentry> |
|
||||||
|
|
||||||
</variablelist> |
|
||||||
|
|
||||||
</sect1> |
|
||||||
|
|
||||||
<sect1 id="recovery-target-settings"> |
|
||||||
|
|
||||||
<title>Recovery Target Settings</title> |
|
||||||
|
|
||||||
<para> |
|
||||||
By default, recovery will recover to the end of the WAL log. The |
|
||||||
following parameters can be used to specify an earlier stopping point. |
|
||||||
At most one of <varname>recovery_target</varname>, |
|
||||||
<varname>recovery_target_lsn</varname>, <varname>recovery_target_name</varname>, |
|
||||||
<varname>recovery_target_time</varname>, or <varname>recovery_target_xid</varname> |
|
||||||
can be used; if more than one of these is specified in the configuration |
|
||||||
file, the last entry will be used. |
|
||||||
</para> |
|
||||||
|
|
||||||
<variablelist> |
|
||||||
<varlistentry id="recovery-target" xreflabel="recovery_target"> |
|
||||||
<term><varname>recovery_target</varname><literal> = 'immediate'</literal> |
|
||||||
<indexterm> |
|
||||||
<primary><varname>recovery_target</varname> recovery parameter</primary> |
|
||||||
</indexterm> |
|
||||||
</term> |
|
||||||
<listitem> |
|
||||||
<para> |
|
||||||
This parameter specifies that recovery should end as soon as a |
|
||||||
consistent state is reached, i.e. as early as possible. When restoring |
|
||||||
from an online backup, this means the point where taking the backup |
|
||||||
ended. |
|
||||||
</para> |
|
||||||
<para> |
|
||||||
Technically, this is a string parameter, but <literal>'immediate'</literal> |
|
||||||
is currently the only allowed value. |
|
||||||
</para> |
|
||||||
</listitem> |
|
||||||
</varlistentry> |
|
||||||
|
|
||||||
<varlistentry id="recovery-target-name" xreflabel="recovery_target_name"> |
|
||||||
<term><varname>recovery_target_name</varname> (<type>string</type>) |
|
||||||
<indexterm> |
|
||||||
<primary><varname>recovery_target_name</varname> recovery parameter</primary> |
|
||||||
</indexterm> |
|
||||||
</term> |
|
||||||
<listitem> |
|
||||||
<para> |
|
||||||
This parameter specifies the named restore point (created with |
|
||||||
<function>pg_create_restore_point()</function>) to which recovery will proceed. |
|
||||||
</para> |
|
||||||
</listitem> |
|
||||||
</varlistentry> |
|
||||||
|
|
||||||
<varlistentry id="recovery-target-time" xreflabel="recovery_target_time"> |
|
||||||
<term><varname>recovery_target_time</varname> (<type>timestamp</type>) |
|
||||||
<indexterm> |
|
||||||
<primary><varname>recovery_target_time</varname> recovery parameter</primary> |
|
||||||
</indexterm> |
|
||||||
</term> |
|
||||||
<listitem> |
|
||||||
<para> |
|
||||||
This parameter specifies the time stamp up to which recovery |
|
||||||
will proceed. |
|
||||||
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>) |
|
||||||
<indexterm> |
|
||||||
<primary><varname>recovery_target_xid</varname> recovery parameter</primary> |
|
||||||
</indexterm> |
|
||||||
</term> |
|
||||||
<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. |
|
||||||
The precise stopping point is also influenced by |
|
||||||
<xref linkend="recovery-target-inclusive"/>. |
|
||||||
</para> |
|
||||||
</listitem> |
|
||||||
</varlistentry> |
|
||||||
|
|
||||||
<varlistentry id="recovery-target-lsn" xreflabel="recovery_target_lsn"> |
|
||||||
<term><varname>recovery_target_lsn</varname> (<type>pg_lsn</type>) |
|
||||||
<indexterm> |
|
||||||
<primary><varname>recovery_target_lsn</varname> recovery parameter</primary> |
|
||||||
</indexterm> |
|
||||||
</term> |
|
||||||
<listitem> |
|
||||||
<para> |
|
||||||
This parameter specifies the LSN of the write-ahead log location up |
|
||||||
to which recovery will proceed. The precise stopping point is also |
|
||||||
influenced by <xref linkend="recovery-target-inclusive"/>. This |
|
||||||
parameter is parsed using the system data type |
|
||||||
<link linkend="datatype-pg-lsn"><type>pg_lsn</type></link>. |
|
||||||
</para> |
|
||||||
</listitem> |
|
||||||
</varlistentry> |
|
||||||
</variablelist> |
|
||||||
|
|
||||||
<para> |
|
||||||
The following options further specify the recovery target, and affect |
|
||||||
what happens when the target is reached: |
|
||||||
</para> |
|
||||||
|
|
||||||
<variablelist> |
|
||||||
<varlistentry id="recovery-target-inclusive" |
|
||||||
xreflabel="recovery_target_inclusive"> |
|
||||||
<term><varname>recovery_target_inclusive</varname> (<type>boolean</type>) |
|
||||||
<indexterm> |
|
||||||
<primary><varname>recovery_target_inclusive</varname> recovery parameter</primary> |
|
||||||
</indexterm> |
|
||||||
</term> |
|
||||||
<listitem> |
|
||||||
<para> |
|
||||||
Specifies whether to stop just after the specified recovery target |
|
||||||
(<literal>true</literal>), or just before the recovery target |
|
||||||
(<literal>false</literal>). |
|
||||||
Applies when <xref linkend="recovery-target-lsn"/>, |
|
||||||
<xref linkend="recovery-target-time"/>, or |
|
||||||
<xref linkend="recovery-target-xid"/> is specified. |
|
||||||
This setting controls whether transactions |
|
||||||
having exactly the target WAL location (LSN), commit time, or transaction ID, respectively, will |
|
||||||
be included in the recovery. Default is <literal>true</literal>. |
|
||||||
</para> |
|
||||||
</listitem> |
|
||||||
</varlistentry> |
|
||||||
|
|
||||||
<varlistentry id="recovery-target-timeline" |
|
||||||
xreflabel="recovery_target_timeline"> |
|
||||||
<term><varname>recovery_target_timeline</varname> (<type>string</type>) |
|
||||||
<indexterm> |
|
||||||
<primary><varname>recovery_target_timeline</varname> recovery parameter</primary> |
|
||||||
</indexterm> |
|
||||||
</term> |
|
||||||
<listitem> |
|
||||||
<para> |
|
||||||
Specifies recovering into a particular timeline. The default is |
|
||||||
to recover along the same timeline that was current when the |
|
||||||
base backup was taken. Setting this to <literal>latest</literal> 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 |
|
||||||
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> |
|
||||||
|
|
||||||
<varlistentry id="recovery-target-action" |
|
||||||
xreflabel="recovery_target_action"> |
|
||||||
<term><varname>recovery_target_action</varname> (<type>enum</type>) |
|
||||||
<indexterm> |
|
||||||
<primary><varname>recovery_target_action</varname> recovery parameter</primary> |
|
||||||
</indexterm> |
|
||||||
</term> |
|
||||||
<listitem> |
|
||||||
<para> |
|
||||||
Specifies what action the server should take once the recovery target is |
|
||||||
reached. The default is <literal>pause</literal>, which means recovery will |
|
||||||
be paused. <literal>promote</literal> means the recovery process will finish |
|
||||||
and the server will start to accept connections. |
|
||||||
Finally <literal>shutdown</literal> will stop the server after reaching the |
|
||||||
recovery target. |
|
||||||
</para> |
|
||||||
<para> |
|
||||||
The intended use of the <literal>pause</literal> setting is 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_wal_replay_resume()</function> (see |
|
||||||
<xref linkend="functions-recovery-control-table"/>), which then |
|
||||||
causes recovery to end. If this recovery target is not the |
|
||||||
desired stopping point, then shut down the server, change the |
|
||||||
recovery target settings to a later target and restart to |
|
||||||
continue recovery. |
|
||||||
</para> |
|
||||||
<para> |
|
||||||
The <literal>shutdown</literal> setting is useful to have the instance ready |
|
||||||
at the exact replay point desired. The instance will still be able to |
|
||||||
replay more WAL records (and in fact will have to replay WAL records |
|
||||||
since the last checkpoint next time it is started). |
|
||||||
</para> |
|
||||||
<para> |
|
||||||
Note that because <filename>recovery.conf</filename> will not be renamed when |
|
||||||
<varname>recovery_target_action</varname> is set to <literal>shutdown</literal>, |
|
||||||
any subsequent start will end with immediate shutdown unless the |
|
||||||
configuration is changed or the <filename>recovery.conf</filename> file is |
|
||||||
removed manually. |
|
||||||
</para> |
|
||||||
<para> |
|
||||||
This setting has no effect if no recovery target is set. |
|
||||||
If <xref linkend="guc-hot-standby"/> is not enabled, a setting of |
|
||||||
<literal>pause</literal> will act the same as <literal>shutdown</literal>. |
|
||||||
</para> |
|
||||||
</listitem> |
|
||||||
</varlistentry> |
|
||||||
|
|
||||||
</variablelist> |
|
||||||
</sect1> |
|
||||||
|
|
||||||
<sect1 id="standby-settings"> |
|
||||||
|
|
||||||
<title>Standby Server Settings</title> |
|
||||||
<variablelist> |
|
||||||
|
|
||||||
<varlistentry id="standby-mode" xreflabel="standby_mode"> |
|
||||||
<term><varname>standby_mode</varname> (<type>boolean</type>) |
|
||||||
<indexterm> |
|
||||||
<primary><varname>standby_mode</varname> recovery parameter</primary> |
|
||||||
</indexterm> |
|
||||||
</term> |
|
||||||
<listitem> |
|
||||||
<para> |
|
||||||
Specifies whether to start the <productname>PostgreSQL</productname> server as |
|
||||||
a standby. If this parameter is <literal>on</literal>, the server will |
|
||||||
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</varname> |
|
||||||
and/or by connecting to the primary server as specified by the |
|
||||||
<varname>primary_conninfo</varname> setting. |
|
||||||
</para> |
|
||||||
</listitem> |
|
||||||
</varlistentry> |
|
||||||
<varlistentry id="primary-conninfo" xreflabel="primary_conninfo"> |
|
||||||
<term><varname>primary_conninfo</varname> (<type>string</type>) |
|
||||||
<indexterm> |
|
||||||
<primary><varname>primary_conninfo</varname> recovery parameter</primary> |
|
||||||
</indexterm> |
|
||||||
</term> |
|
||||||
<listitem> |
|
||||||
<para> |
|
||||||
Specifies a connection string to be used for the standby server |
|
||||||
to connect with the primary. This string is in the format |
|
||||||
described in <xref linkend="libpq-connstring"/>. 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> |
|
||||||
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 suitably-privileged role |
|
||||||
on the primary (see |
|
||||||
<xref linkend="streaming-replication-authentication"/>). |
|
||||||
A password needs to be provided too, if the primary demands password |
|
||||||
authentication. It can be provided in the |
|
||||||
<varname>primary_conninfo</varname> string, or in a separate |
|
||||||
<filename>~/.pgpass</filename> file on the standby server (use |
|
||||||
<literal>replication</literal> as the database name). |
|
||||||
Do not specify a database name in the |
|
||||||
<varname>primary_conninfo</varname> string. |
|
||||||
</para> |
|
||||||
<para> |
|
||||||
This setting has no effect if <varname>standby_mode</varname> is <literal>off</literal>. |
|
||||||
</para> |
|
||||||
</listitem> |
|
||||||
</varlistentry> |
|
||||||
<varlistentry id="primary-slot-name" xreflabel="primary_slot_name"> |
|
||||||
<term><varname>primary_slot_name</varname> (<type>string</type>) |
|
||||||
<indexterm> |
|
||||||
<primary><varname>primary_slot_name</varname> recovery parameter</primary> |
|
||||||
</indexterm> |
|
||||||
</term> |
|
||||||
<listitem> |
|
||||||
<para> |
|
||||||
Optionally specifies an existing replication slot to be used when |
|
||||||
connecting to the primary via streaming replication to control |
|
||||||
resource removal on the upstream node |
|
||||||
(see <xref linkend="streaming-replication-slots"/>). |
|
||||||
This setting has no effect if <varname>primary_conninfo</varname> is not |
|
||||||
set. |
|
||||||
</para> |
|
||||||
</listitem> |
|
||||||
</varlistentry> |
|
||||||
<varlistentry id="trigger-file" xreflabel="trigger_file"> |
|
||||||
<term><varname>trigger_file</varname> (<type>string</type>) |
|
||||||
<indexterm> |
|
||||||
<primary><varname>trigger_file</varname> recovery parameter</primary> |
|
||||||
</indexterm> |
|
||||||
</term> |
|
||||||
<listitem> |
|
||||||
<para> |
|
||||||
Specifies a trigger file whose presence ends recovery in the |
|
||||||
standby. Even if this value is not set, you can still promote |
|
||||||
the standby using <command>pg_ctl promote</command> or calling |
|
||||||
<function>pg_promote</function>. |
|
||||||
This setting has no effect if <varname>standby_mode</varname> is <literal>off</literal>. |
|
||||||
</para> |
|
||||||
</listitem> |
|
||||||
</varlistentry> |
|
||||||
|
|
||||||
<varlistentry id="recovery-min-apply-delay" xreflabel="recovery_min_apply_delay"> |
|
||||||
<term><varname>recovery_min_apply_delay</varname> (<type>integer</type>) |
|
||||||
<indexterm> |
|
||||||
<primary><varname>recovery_min_apply_delay</varname> recovery parameter</primary> |
|
||||||
</indexterm> |
|
||||||
</term> |
|
||||||
<listitem> |
|
||||||
<para> |
|
||||||
By default, a standby server restores WAL records from the |
|
||||||
primary as soon as possible. It may be useful to have a time-delayed |
|
||||||
copy of the data, offering opportunities to correct data loss errors. |
|
||||||
This parameter allows you to delay recovery by a fixed period of time, |
|
||||||
measured in milliseconds if no unit is specified. For example, if |
|
||||||
you set this parameter to <literal>5min</literal>, the standby will |
|
||||||
replay each transaction commit only when the system time on the standby |
|
||||||
is at least five minutes past the commit time reported by the master. |
|
||||||
</para> |
|
||||||
<para> |
|
||||||
It is possible that the replication delay between servers exceeds the |
|
||||||
value of this parameter, in which case no delay is added. |
|
||||||
Note that the delay is calculated between the WAL time stamp as written |
|
||||||
on master and the current time on the standby. Delays in transfer |
|
||||||
because of network lag or cascading replication configurations |
|
||||||
may reduce the actual wait time significantly. If the system |
|
||||||
clocks on master and standby are not synchronized, this may lead to |
|
||||||
recovery applying records earlier than expected; but that is not a |
|
||||||
major issue because useful settings of this parameter are much larger |
|
||||||
than typical time deviations between servers. |
|
||||||
</para> |
|
||||||
<para> |
|
||||||
The delay occurs only on WAL records for transaction commits. |
|
||||||
Other records are replayed as quickly as possible, which |
|
||||||
is not a problem because MVCC visibility rules ensure their effects |
|
||||||
are not visible until the corresponding commit record is applied. |
|
||||||
</para> |
|
||||||
<para> |
|
||||||
The delay occurs once the database in recovery has reached a consistent |
|
||||||
state, until the standby is promoted or triggered. After that the standby |
|
||||||
will end recovery without further waiting. |
|
||||||
</para> |
|
||||||
<para> |
|
||||||
This parameter is intended for use with streaming replication deployments; |
|
||||||
however, if the parameter is specified it will be honored in all cases. |
|
||||||
|
|
||||||
<varname>hot_standby_feedback</varname> will be delayed by use of this feature |
|
||||||
which could lead to bloat on the master; use both together with care. |
|
||||||
|
|
||||||
<warning> |
|
||||||
<para> |
|
||||||
Synchronous replication is affected by this setting when <varname>synchronous_commit</varname> |
|
||||||
is set to <literal>remote_apply</literal>; every <literal>COMMIT</literal> |
|
||||||
will need to wait to be applied. |
|
||||||
</para> |
|
||||||
</warning> |
|
||||||
</para> |
|
||||||
</listitem> |
|
||||||
</varlistentry> |
|
||||||
|
|
||||||
</variablelist> |
|
||||||
</sect1> |
|
||||||
|
|
||||||
</chapter> |
|
||||||
@ -1,158 +0,0 @@ |
|||||||
# ------------------------------- |
|
||||||
# PostgreSQL recovery config file |
|
||||||
# ------------------------------- |
|
||||||
# |
|
||||||
# Edit this file to provide the parameters that PostgreSQL needs to |
|
||||||
# perform an archive recovery of a database, or to act as a replication |
|
||||||
# standby. |
|
||||||
# |
|
||||||
# If "recovery.conf" is present in the PostgreSQL data directory, it is |
|
||||||
# read on postmaster startup. After successful recovery, it is renamed |
|
||||||
# to "recovery.done" to ensure that we do not accidentally re-enter |
|
||||||
# archive recovery or standby mode. |
|
||||||
# |
|
||||||
# This file consists of lines of the form: |
|
||||||
# |
|
||||||
# name = value |
|
||||||
# |
|
||||||
# Comments are introduced with '#'. |
|
||||||
# |
|
||||||
# The complete list of option names and allowed values can be found |
|
||||||
# in the PostgreSQL documentation. |
|
||||||
# |
|
||||||
#--------------------------------------------------------------------------- |
|
||||||
# ARCHIVE RECOVERY PARAMETERS |
|
||||||
#--------------------------------------------------------------------------- |
|
||||||
# |
|
||||||
# restore_command |
|
||||||
# |
|
||||||
# specifies the shell command that is executed to copy log files |
|
||||||
# back from archival storage. The command string may contain %f, |
|
||||||
# which is replaced by the name of the desired log file, and %p, |
|
||||||
# which is replaced by the absolute path to copy the log file to. |
|
||||||
# |
|
||||||
# This parameter is *required* for an archive recovery, but optional |
|
||||||
# for streaming replication. |
|
||||||
# |
|
||||||
# It is important that the command return nonzero exit status on failure. |
|
||||||
# The command *will* be asked for log files that are not present in the |
|
||||||
# archive; it must return nonzero when so asked. |
|
||||||
# |
|
||||||
# NOTE that the basename of %p will be different from %f; do not |
|
||||||
# expect them to be interchangeable. |
|
||||||
# |
|
||||||
#restore_command = '' # e.g. 'cp /mnt/server/archivedir/%f %p' |
|
||||||
# |
|
||||||
# |
|
||||||
# archive_cleanup_command |
|
||||||
# |
|
||||||
# specifies an optional shell command to execute at every restartpoint. |
|
||||||
# This can be useful for cleaning up the archive of a standby server. |
|
||||||
# |
|
||||||
#archive_cleanup_command = '' |
|
||||||
# |
|
||||||
# recovery_end_command |
|
||||||
# |
|
||||||
# specifies an optional shell command to execute at completion of recovery. |
|
||||||
# This can be useful for cleaning up after the restore_command. |
|
||||||
# |
|
||||||
#recovery_end_command = '' |
|
||||||
# |
|
||||||
#--------------------------------------------------------------------------- |
|
||||||
# RECOVERY TARGET PARAMETERS |
|
||||||
#--------------------------------------------------------------------------- |
|
||||||
# |
|
||||||
# By default, recovery will rollforward to the end of the WAL log. |
|
||||||
# If you want to stop rollforward at a specific point, you |
|
||||||
# must set a recovery target. |
|
||||||
# |
|
||||||
# You may set a recovery target either by transactionId, by name, by |
|
||||||
# timestamp or by WAL location (LSN). Recovery may either include or |
|
||||||
# exclude the transaction(s) with the recovery target value (i.e., |
|
||||||
# stop either just after or just before the given target, |
|
||||||
# respectively). |
|
||||||
# |
|
||||||
# |
|
||||||
#recovery_target_name = '' # e.g. 'daily backup 2011-01-26' |
|
||||||
# |
|
||||||
#recovery_target_time = '' # e.g. '2004-07-14 22:39:00 EST' |
|
||||||
# |
|
||||||
#recovery_target_xid = '' |
|
||||||
# |
|
||||||
#recovery_target_lsn = '' # e.g. '0/70006B8' |
|
||||||
# |
|
||||||
#recovery_target_inclusive = true |
|
||||||
# |
|
||||||
# |
|
||||||
# Alternatively, you can request stopping as soon as a consistent state |
|
||||||
# is reached, by uncommenting this option. |
|
||||||
# |
|
||||||
#recovery_target = 'immediate' |
|
||||||
# |
|
||||||
# |
|
||||||
# If you want to recover into a timeline other than the "main line" shown in |
|
||||||
# pg_control, specify the timeline number here, or write 'latest' to get |
|
||||||
# the latest branch for which there's a history file. |
|
||||||
# |
|
||||||
#recovery_target_timeline = 'latest' |
|
||||||
# |
|
||||||
# |
|
||||||
# If recovery_target_action = 'pause', recovery will pause when the |
|
||||||
# recovery target is reached. The pause state will continue until |
|
||||||
# pg_wal_replay_resume() is called. This setting has no effect if |
|
||||||
# no recovery target is set. If hot_standby is not enabled then the |
|
||||||
# server will shutdown instead, though you may request this in |
|
||||||
# any case by specifying 'shutdown'. |
|
||||||
# |
|
||||||
#recovery_target_action = 'pause' |
|
||||||
# |
|
||||||
#--------------------------------------------------------------------------- |
|
||||||
# STANDBY SERVER PARAMETERS |
|
||||||
#--------------------------------------------------------------------------- |
|
||||||
# |
|
||||||
# standby_mode |
|
||||||
# |
|
||||||
# When standby_mode is enabled, the PostgreSQL server will work as a |
|
||||||
# standby. It will continuously wait for the additional XLOG records, using |
|
||||||
# restore_command and/or primary_conninfo. |
|
||||||
# |
|
||||||
#standby_mode = off |
|
||||||
# |
|
||||||
# primary_conninfo |
|
||||||
# |
|
||||||
# If set, the PostgreSQL server will try to connect to the primary using this |
|
||||||
# connection string and receive XLOG records continuously. |
|
||||||
# |
|
||||||
#primary_conninfo = '' # e.g. 'host=localhost port=5432' |
|
||||||
# |
|
||||||
# If set, the PostgreSQL server will use the specified replication slot when |
|
||||||
# connecting to the primary via streaming replication to control resource |
|
||||||
# removal on the upstream node. This setting has no effect if primary_conninfo |
|
||||||
# is not set. |
|
||||||
# |
|
||||||
#primary_slot_name = '' |
|
||||||
# |
|
||||||
# By default, a standby server keeps restoring XLOG records from the |
|
||||||
# primary indefinitely. If you want to stop the standby mode, finish recovery |
|
||||||
# and open the system in read/write mode, specify a path to a trigger file. |
|
||||||
# The server will poll the trigger file path periodically and start as a |
|
||||||
# primary server when it's found. |
|
||||||
# |
|
||||||
#trigger_file = '' |
|
||||||
# |
|
||||||
# By default, a standby server restores XLOG records from the primary as |
|
||||||
# soon as possible. If you want to explicitly delay the replay of committed |
|
||||||
# transactions from the master, specify a minimum apply delay. For example, |
|
||||||
# if you set this parameter to 5min, the standby will replay each transaction |
|
||||||
# commit only when the system time on the standby is at least five minutes |
|
||||||
# past the commit time reported by the master. |
|
||||||
# |
|
||||||
#recovery_min_apply_delay = 0 |
|
||||||
# |
|
||||||
#--------------------------------------------------------------------------- |
|
||||||
# HOT STANDBY PARAMETERS |
|
||||||
#--------------------------------------------------------------------------- |
|
||||||
# |
|
||||||
# Hot Standby related parameters are listed in postgresql.conf |
|
||||||
# |
|
||||||
#--------------------------------------------------------------------------- |
|
||||||
Loading…
Reference in new issue