max_standby_streaming_delay

瀚高PG实验室

于 2018-03-16 14:52:55 发布

阅读量2.2k

点赞数

CC 4.0 BY-SA版权

分类专栏： PostgreSQL之体系结构文章标签： sql

本文链接：https://blog.csdn.net/pg_hgdb/article/details/79581773

PostgreSQL之体系结构专栏收录该内容

84 篇文章

订阅专栏

作者：瀚高PG实验室（Highgo PG Lab）- 天蝎座

max_standby_archive_delay (integer)

When Hot Standby is active, this parameter determines how long the
standby server should wait before canceling standby queries that
conflict with about-to-be-applied WAL entries, as described in Section
25.5.2. max_standby_archive_delay applies when WAL data is being read from WAL archive (and is therefore not current). The default is 30
seconds. Units are milliseconds if not specified. A value of -1 allows
the standby to wait forever for conflicting queries to complete. This
parameter can only be set in the postgresql.conf file or on the server
command line.

Note that max_standby_archive_delay is not the same as the maximum
length of time a query can run before cancellation; rather it is the
maximum total time allowed to apply any one WAL segment’s data. Thus,
if one query has resulted in significant delay earlier in the WAL
segment, subsequent conflicting queries will have much less grace
time.

max_standby_streaming_delay (integer)

When Hot Standby is active, this parameter determines how long the
standby server should wait before canceling standby queries that
conflict with about-to-be-applied WAL entries, as described in Section
25.5.2. max_standby_streaming_delay applies when WAL data is being received via streaming replication. The default is 30 seconds. Units
are milliseconds if not specified. A value of -1 allows the standby to
wait forever for conflicting queries to complete. This parameter can
only be set in the postgresql.conf file or on the server command line.

Note that max_standby_streaming_delay is not the same as the maximum
length of time a query can run before cancellation; rather it is the
maximum total time allowed to apply WAL data once it has been received
from the primary server. Thus, if one query has resulted in
significant delay, subsequent conflicting queries will have much less
grace time until the standby server has caught up again.

上面是官网对于这两个参数的介绍。

简单来说，这两个参数用于控制两个可能的来源（即传送归档日志和流复制）的数据块更改在终端查询执行之前的最大等待时间。这些值越大会优先考虑执行查询而不是应该用这些数据块。

注：这么表述感觉不太贴切，实际上官网的介绍中有这么一句话：“请注意，max_standby_streaming_delay与查询在取消前可以运行的最大时间长度不同; 而是一旦从主服务器接收到WAL数据就允许应用WAL数据的最大总时间。”
所以个人认为，上面的解释相对来说思路是对的，但是可能有些偏差，并非查询执行之前的最大等待时间。
允许应用WAL数据的最大总时间（max_standby_streaming_delay） = “查询执行之前的最大等待时间+ 应用WAL数据块的时间”

实际应用场景：

主库执行了DROP某TABLE的操作, 而standby库上某用户正在查询这个表的数据. 当流复制中的standby库接收到这个改变并且准备在standby库上apply的时候, 如果查询还在执行, 就发生冲突了, 这个时候standby 要判断是否要cancel掉这个查询使得apply可以正常进行下去, 或者standby选择等待多长时间.
主库执行删除表空间或者删除库等相关的操作也会遇到上面的问题.
更隐晦的是主库上执行了vacuum操作, 这些被vacuum掉的tuple, 可能是standby库上的查询可见的TUPLE, 也会发生冲突.
其他原因。

如果值等于-1表示永不因为应用数据块和查询冲突的原因cancel standby上的SQL.
如果设置了一个值如30秒, 那么在cancel 冲突的查询前等待一定时间。

至于等待时间多少，需要去翻看源代码中如何定义，参考文章：

http://blog.163.com/digoal@126/blog/static/163877040201232021644846/