Postgres热备和长期查询奴隶

use*_*516 12 postgresql replication database-replication

问题:在热备模式下,在从属设备上应用WAL更新(从属角色是报告数据库服务器)时,是否可以运行长时间运行的查询(30秒+)?它现在的工作方式是,要么设置下面的参数来杀死长时间运行的查询,以便可以应用WAL更新,或者无限期地延迟WAL更新,直到没有运行查询来应用它们.我们可以同时拥有吗?长时间运行的查询和WAL更新同时应用?

案例实现:我们目前正在使用热备模式来同步从一个主服务器到一个服务器的任何更改.slave角色是一个报告数据库服务器,其查询不断地并发地运行(一些以ms为单位,一些以秒为单位,一些以分钟为单位.)在从站上运行没有活动查询的间隙是非常罕见的.

我们调整了这两个参数,以便在热备用上进行长时间查询:

max_standby_archive_delay = -1  # max delay before canceling queries
max_standby_streaming_delay = -1  # max delay before canceling queries
Run Code Online (Sandbox Code Playgroud)

在postgres邮件列表中查看类似于我们的存档邮件问题:

http://www.postgresql.org/message-id/AANLkTinLg+bpzcjzdndsnGGNFC=D1OsVh+hKb85A-s=n@mail.gmail.com

我理解在查询运行时阻止WAL更新应用于从属的概念.但是,我认为与使用MVCC,从属节点上的活动查询的(长期运行30秒+)可以运行从一个版本/快照读书,一边在施加WAL更新,因此后续的查询将得到WAL更新时WAL事务已提交.我还没有完全消化PostgreSQL中使用的MVCC模型[ https://devcenter.heroku.com/articles/postgresql-concurrency],所以这只是我的假设 - 即使表在一个表中被删除/截断WAL更新,当前运行的查询应该仍然有效,因为它正在使用它查询的表的版本/快照?

简介:无论如何(即使有第三方扩展)我们可以从主服务器同步从服务器并将主服务器的更新立即应用于从服务器,同时让任何执行时间的查询继续运行直到他们在备用服务器上完成/奴隶?如果Hot Standby无法做到这一点,你会为这种情况推荐什么?我们的情况是,我们正在不断地运行postgres并同时运行(一些以ms为单位,一些以秒为单位,一些以分钟为单位),几乎没有时间来应用WAL更新.我们使用过Bucardo,但在这种情况下这不是一个好的选择,因为我们需要同步200多个表,包括视图以及除主数据库之外的40多个其他数据库.

任何帮助将不胜感激.

谢谢!

use*_*516 20

感谢Guillaume的回答,但幸运的是,从PostgreSQL 9.1开始,PostgreSQL有hot_standby_feedback选项(你在postgresql.conf中的备用服务器上设置它),它不会杀死长时间运行的查询,并允许WAL更新到备用服务器.这个答案归功于PostgreSQL邮件列表中的三个人(Raja/Albe/Scott),他们在邮件线程中帮助了我.希望这对于在stackoverflow上搜索此答案的人有所帮助.电子邮件主题可以在这里找到:

http://www.postgresql.org/message-id/D274E3C1.1113E8%awilliams@dresourcesgroup.com

http://www.postgresql.org/docs/9.1/static/hot-standby.html

摘抄:

如果发现备用查询取消的数量是不可接受的,则存在补救可能性.第一个选项是设置参数hot_standby_feedback,以防止VACUUM删除最近死行,因此不会发生清除冲突.如果这样做,您应该注意这将延迟清除主数据库上的死行,这可能会导致不希望的表膨胀.但是,清理情况不会比备用查询直接在主服务器上运行更糟糕,并且您仍然可以获得将备份执行卸载到备用服务器上的好处.max_standby_archive_delay在这种情况下必须保持较大,因为延迟的WAL文件可能已包含与所需备用查询冲突的条目.

方案实施:

以下是您postgresql.conf应在备用服务器上配置的内容:

max_standby_archive_delay = -1
max_standby_streaming_delay = -1
hot_standby_feedback = on
Run Code Online (Sandbox Code Playgroud)

  • hot_standby_feedback 很危险,因为它会强制 autovacuum 等待 master,并且您可以轻松地开始在某些工作负载上快速释放空间。请谨慎使用。 (5认同)
  • 我们有一个类似的用例,主服务器和副本服务器之间的流式复制。副本大量用于读取查询。我们尝试了上述三个属性,现在没有看到“冲突”错误。然而,我们发现延迟高达“2000”秒,平均约为“500”秒。我们的用例无法容忍如此高的延迟。我们还能做些什么来降低延迟*并且*不会导致“冲突”错误。谢谢! (3认同)

Gui*_* F. 0

PostgreSQL 是一个非常好的数据库引擎,因为大多数查询不会锁定表。在内部,它在表中的每行都有一种修订系统,这意味着它可以在其他读取事务期间继续写入 WAL。

日志也非常耐延迟,除非您有大量流量,否则它总是会在某个时刻赶上。

只要确保您不使用 Lock 命令,就可以了。