public inbox for [email protected]
help / color / mirror / Atom feedcategory of min_recovery_apply_delay
2+ messages / 2 participants
[nested] [flat]
* category of min_recovery_apply_delay
@ 2014-02-01 09:49 Fujii Masao <[email protected]>
2014-04-16 23:15 ` Re: category of min_recovery_apply_delay Bruce Momjian <[email protected]>
0 siblings, 1 reply; 2+ messages in thread
From: Fujii Masao @ 2014-02-01 09:49 UTC (permalink / raw)
To: pgsql-docs
Hi,
In the document, min_recovery_apply_delay is categorized into Archive
Recovery Settings.
But ISTM that its category should be Standby Server Settings because
it's almost used in
replication environment. BTW, in recovery.conf.sample, it's
categorized into Standby Server
Settings. Patch attached.
Regards,
--
Fujii Masao
--
Sent via pgsql-docs mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
Attachments:
[text/x-diff] doc_about_min_recovery_apply_delay.patch (6.2K, 2-doc_about_min_recovery_apply_delay.patch)
download | inline diff:
*** a/doc/src/sgml/recovery-config.sgml
--- b/doc/src/sgml/recovery-config.sgml
***************
*** 142,197 **** restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"' # Windows
</listitem>
</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>
</sect1>
--- 142,147 ----
***************
*** 449,454 **** restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"' # Windows
--- 399,454 ----
</listitem>
</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>
</sect1>
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: category of min_recovery_apply_delay
2014-02-01 09:49 category of min_recovery_apply_delay Fujii Masao <[email protected]>
@ 2014-04-16 23:15 ` Bruce Momjian <[email protected]>
0 siblings, 0 replies; 2+ messages in thread
From: Bruce Momjian @ 2014-04-16 23:15 UTC (permalink / raw)
To: Fujii Masao <[email protected]>; +Cc: pgsql-docs
On Sat, Feb 1, 2014 at 06:49:50PM +0900, Fujii Masao wrote:
> Hi,
>
> In the document, min_recovery_apply_delay is categorized into Archive
> Recovery Settings.
> But ISTM that its category should be Standby Server Settings because
> it's almost used in
> replication environment. BTW, in recovery.conf.sample, it's
> categorized into Standby Server
> Settings. Patch attached.
Applied.
--
Bruce Momjian <[email protected]> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
--
Sent via pgsql-docs mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2014-04-16 23:15 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2014-02-01 09:49 category of min_recovery_apply_delay Fujii Masao <[email protected]>
2014-04-16 23:15 ` Bruce Momjian <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox