pg流复制不设置和设置synchronous_standby_names的区别

原创
07/26 16:36
阅读数 9

synchronous_commit( enum)

指定在数据库服务器向客户端返回“成功”指示之前必须完成多少 WAL 处理。有效值为remote_apply、on(默认值)remote_write、local、 和off。

如果synchronous_standby_names为空,则唯一有意义的设置是on和off;remote_apply,remote_write并且local都提供与 相同的本地同步级别on。所有非off模式的本地行为是等待 WAL 本地刷新到磁盘。在off模式下,没有等待,因此在向客户端报告成功与稍后保证事务安全以防止服务器崩溃之间可能存在延迟。(最大延迟是wal_writer_delay 的三倍。)与fsync不同,将此参数设置为off不会造成任何数据库不一致的风险:操作系统或数据库崩溃可能会导致一些最近据称已提交的事务丢失,但数据库状态将与这些事务已完全中止一样。因此,synchronous_commit当性能比事务持久性的确切确定性更重要时,关闭可能是一个有用的替代方法。

如果synchronous_standby_names为非空,synchronous_commit还控制事务提交是否将等待它们的 WAL 记录在备用服务器上被处理。

当设置为 时remote_apply,提交将等待,直到来自当前同步备用数据库的回复表明他们已收到事务的提交记录并应用它,以便它对备用数据库上的查询可见,并写入备用服务器上的持久存储。由于等待 WAL 重放,这将导致比以前的设置更大的提交延迟。当设置为 时on,提交等待,直到来自当前同步备用数据库的回复表明他们已收到事务的提交记录并将其刷新到持久存储。这确保事务不会丢失,除非主数据库和所有同步备用数据库都遭受数据库存储损坏。当设置为remote_write,提交将等待,直到来自当前同步备用数据库的回复表明他们已收到事务的提交记录并将其写入其文件系统。如果PostgreSQL的备用实例崩溃,则此设置可确保数据保留,但如果备用实例发生操作系统级崩溃,则无法确保数据保留,因为数据不一定已到达备用数据库上的持久存储。该设置local导致提交等待本地刷新到磁盘,但不等待复制。当使用同步复制时,这通常是不可取的,但为了完整性而提供。

该参数可以随时更改;任何一个事务的行为由它提交时生效的设置决定。因此,让一些事务同步提交而其他事务异步提交是可能且有用的。例如,要在默认值相反时异步提交单个多语句事务,请SET LOCAL synchronous_commit TO OFF在事务内发出。

表总结了synchronous_commit设置的功能。

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部