有一套系统刚搭建好 HOT-Standby, 为了降低主库压力,准备让数据仓库在备库上抽取,这里需要修改参数 max_standby_streaming_delay
,否则在备库上查询时间超过 30 秒时会报错,关于这个报错可以参考之前写的blog: https://postgres.fun/20110530103706.html ,但今天在修改这个参数时,出现了奇怪的一幕,以下为详细信息。
修改 postgresql.conf 文件
设置参数
1 |
max_standby_streaming_delay = 3600s |
备注:修改参数 max_standby_streaming_delay
,准备修改成一小时,当在备库上执行查询操作时,恰当备库需要应用主库发来的WAL日志,此时两者发生冲突,那么允许备库上的SQL的最大执行时间为 1 小时,超过一小时后,备库会 cancel 备库上的查询语句。
参数修改后,重新载入
1 |
[postgres@db-192-168-1-25](mailto:postgres@db-192-168-1-25)-> pg_ctl reload -D $PGDATA |
再次查询 max_standby_streaming_delay 值
1 |
netpk=> show max_standby_streaming_delay; |
备注:这里出现了奇怪的一幕,明明将参数 max_standby_streaming_delay
值设置成了 3600 秒,而仍然显示默认的 30 秒,这个参数修改后是不需要重启 PostgreSQL 的。
尝试重启备库
由于是备库,参数 max_standby_streaming_delay
在线修改不成功,于是准备重启下备库, 接下来报了下面这个 FATAL。
1 |
[postgres@db-192-168-1-25](mailto:postgres@db-192-168-1-25)-> FATAL: 3600000 is outside the valid range for parameter "max_standby_streaming_delay" (-1 .. 2147483) |
备注: 奇怪了,根据提示,参数 max_standby_streaming_delay
值超出了设置范围,难道这个参数有限制,于是迅速查看手册,遗憾的是,9.0 上的手册没有提到 max_standby_streaming_delay
参数有限制值, 没办法,只有问 GOOGLE 老师了, 还好运气不错。
查询官网
查询官网,http://archives.postgresql.org/
The limit on max_standby_streaming_delay is currently 35 minutes
(around) – or you have to set it to unlimited. This is because the GUC
is limited to MAX_INT/1000, unit milliseconds.
Is there a reason for the /1000, or is it just an oversight thinking
the unit was in seconds?
If we can get rid of the /1000, it would make the limit over three
weeks, which seems much more reasonable. Or if we made it a 64-bit
counter it would go away completely.
备注:运气不错,查到了相关的回复,上面是说 max_standby_streaming_delay 参数当前的限制值为 35 分钟, 也可以将值设为 “-1” ,表示不限制。这个限制可能会在后期版本中修改。
总结
-
合理的设置
max_standby_streaming_delay
的值,主要还是要看备库的用途,是高可用,还是用来
分担主库负载,比如跑些报表,数据抽取之类的,如果是高可用,设置较小的值比较合理;因为备库
需要时刻同步主库的数据;如果是为了分担主库负载 ,那么可以设置较大的值(35 min), 那么长时
间的报表,或者仓库抽取之类的工作可以进行; -
$PGDATA/postgresql.conf
参数修改后,最好还是登陆到数据库里用” show parameter “ 命令去查看下,因为有些参数有范围限制,即使设置超出范围的参数值,在 reload 也没报错,max_standby_streaming_delay
参数就是这样。
原创文章,作者:254126420,如若转载,请注明出处:https://blog.ytso.com/236424.html