doc: move min_recovery_apply_delay into the right section
Patch by Fujii Masao
This commit is contained in:
Bruce Momjian
parent
8c349ba5c0
commit
be5f7fff47
@ -142,56 +142,6 @@ restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"' # Windows
|
|||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
|
||||||
<varlistentry id="min-recovery-apply-delay" xreflabel="min_recovery_apply_delay">
|
|
||||||
<term><varname>min_recovery_apply_delay</varname> (<type>integer</type>)</term>
|
|
||||||
<indexterm>
|
|
||||||
<primary><varname>min_recovery_apply_delay</> recovery parameter</primary>
|
|
||||||
</indexterm>
|
|
||||||
<listitem>
|
|
||||||
<para>
|
|
||||||
By default, a standby server keeps restoring WAL records from the
|
|
||||||
primary as soon as possible. It may be useful to have a time-delayed
|
|
||||||
copy of the data, offering various options to correct data loss errors.
|
|
||||||
This parameter allows you to delay recovery by a fixed period of time,
|
|
||||||
specified 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 timestamp as written
|
|
||||||
on master and the time on the current standby. Delays
|
|
||||||
in transfer because of networks or cascading replication configurations
|
|
||||||
may reduce the actual wait time significantly. If the system
|
|
||||||
clocks on master and standby are not synchronised, this may lead to
|
|
||||||
recovery applying records earlier than expected but is not a major issue
|
|
||||||
because the useful settings of the parameter are much larger than
|
|
||||||
typical time deviation between the servers. Be careful to allow for
|
|
||||||
different timezone settings on master and standby.
|
|
||||||
</para>
|
|
||||||
<para>
|
|
||||||
The delay occurs only on WAL records for COMMIT and Restore Points.
|
|
||||||
Other records may be replayed earlier than the specified delay, which
|
|
||||||
is not an issue for MVCC though may potentially increase the number
|
|
||||||
of recovery conflicts generated.
|
|
||||||
</para>
|
|
||||||
<para>
|
|
||||||
The delay occurs 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 honoured in all cases.
|
|
||||||
Synchronous replication is not affected by this setting because there is
|
|
||||||
not yet any setting to request synchronous apply of transaction commits.
|
|
||||||
<varname>hot_standby_feedback</> will be delayed by use of this feature
|
|
||||||
which could lead to bloat on the master; use both together with care.
|
|
||||||
</para>
|
|
||||||
</listitem>
|
|
||||||
</varlistentry>
|
|
||||||
|
|
||||||
</variablelist>
|
</variablelist>
|
||||||
|
|
||||||
</sect1>
|
</sect1>
|
||||||
@ -449,6 +399,56 @@ restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"' # Windows
|
|||||||
</listitem>
|
</listitem>
|
||||||
</varlistentry>
|
</varlistentry>
|
||||||
|
|
||||||
|
<varlistentry id="min-recovery-apply-delay" xreflabel="min_recovery_apply_delay">
|
||||||
|
<term><varname>min_recovery_apply_delay</varname> (<type>integer</type>)</term>
|
||||||
|
<indexterm>
|
||||||
|
<primary><varname>min_recovery_apply_delay</> recovery parameter</primary>
|
||||||
|
</indexterm>
|
||||||
|
<listitem>
|
||||||
|
<para>
|
||||||
|
By default, a standby server keeps restoring WAL records from the
|
||||||
|
primary as soon as possible. It may be useful to have a time-delayed
|
||||||
|
copy of the data, offering various options to correct data loss errors.
|
||||||
|
This parameter allows you to delay recovery by a fixed period of time,
|
||||||
|
specified 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 timestamp as written
|
||||||
|
on master and the time on the current standby. Delays
|
||||||
|
in transfer because of networks or cascading replication configurations
|
||||||
|
may reduce the actual wait time significantly. If the system
|
||||||
|
clocks on master and standby are not synchronised, this may lead to
|
||||||
|
recovery applying records earlier than expected but is not a major issue
|
||||||
|
because the useful settings of the parameter are much larger than
|
||||||
|
typical time deviation between the servers. Be careful to allow for
|
||||||
|
different timezone settings on master and standby.
|
||||||
|
</para>
|
||||||
|
<para>
|
||||||
|
The delay occurs only on WAL records for COMMIT and Restore Points.
|
||||||
|
Other records may be replayed earlier than the specified delay, which
|
||||||
|
is not an issue for MVCC though may potentially increase the number
|
||||||
|
of recovery conflicts generated.
|
||||||
|
</para>
|
||||||
|
<para>
|
||||||
|
The delay occurs 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 honoured in all cases.
|
||||||
|
Synchronous replication is not affected by this setting because there is
|
||||||
|
not yet any setting to request synchronous apply of transaction commits.
|
||||||
|
<varname>hot_standby_feedback</> will be delayed by use of this feature
|
||||||
|
which could lead to bloat on the master; use both together with care.
|
||||||
|
</para>
|
||||||
|
</listitem>
|
||||||
|
</varlistentry>
|
||||||
|
|
||||||
</variablelist>
|
</variablelist>
|
||||||
</sect1>
|
</sect1>
|
||||||
|
|
||||||
|
|||||||
Loading…
x
Reference in New Issue
Block a user