[译]“SYNCHRONOUS_COMMIT”参数和流复制

段落引用原文作者： Kaarel Moppel
翻译：Tracy
原文链接：https://www.cybertec-postgresql.com/en/the-synchronous_commit-parameter

如果您还不熟悉 Postgres 的“synchronous_commit” 参数，那么您绝对应该继续往下阅读。它是具有多个参数值的重要参数之一，这对于新手DBA来说可能有点令人生畏。并且在PostgreSQL 9.6 中添加了另一个名为“remote_apply”的新选项，我会讲述这个选项，同时也尝试用简单的术语解释其他选项并在流复制场景下对于是否使用同步复制进行一些性能测试。

可用选项

Postgres9.5版之前的允许值是“on”、“remote_write”、“local”和“off”，9.6版加入了“remote_apply”。这些值可以用下面的文本格式内容做简短的描述。注意！后3个值仅在同步流复制模式下有效，当“synchronous_standby_names”参数中未列出任何副本时，将回退到“on”值。

• on – 事务提交总是等到数据真正刷新到事务日志（又名WAL或XLOG），以确保事务真正持久化。在同步流复制模式下，副本也需要这样做。

• off - 在事务实际刷新到事务日志之前，可以向调用客户端确认提交，从而在服务器崩溃的情况下丢失一些最近（默认情况下小于 1 秒）宣称提交的事务。同步复制被忽略。这是最著名的 Postgres 性能调整之一。

• local - 仅在主节点上强制“开启”行为（保证数据刷新）。例如，用户可以在会话级别设置这个参数值,以加快主节点上非关键数据导入的速度。

• remote_write - 提供比“on”弱的保证，如果主节点进行了有保证的刷新并且副本从操作系统获得写入确认（如果副本机器在命中存储之前崩溃，则容易导致副本损坏），则事务被视为已提交。

• remote_apply - 提供最强的副本一致性 - 提交不会返回直到副本刷新并且应用数据。客户端可以查询主数据库或备用数据库，它们会看到一致的数据。

不同“synchronous_commit”设置对性能的影响

现在，这些不同的值在流复制场景中对性能有何影响？从逻辑上讲，我们可以假设我们可以根据给定的保证（应该转化为完成的工作量）来对他们进行排序，如下所示：

off（异步）> on（异步）> remote_write（同步）> on|local（同步）> remote_apply（同步）

但是当使用更高的一致性级别时，后果在数字上如何体现？事务提交会慢多少？让我们使用老伙伴 pgbench 再次进行一组快速测试！

为了测试，我在 AWS 上搭建了一主备环境，在不同的参数设置下运行同一个脚本，每次修改参数是都会重新数据库，并重新初始化测试模式。可以在此处找到该脚本，为了简洁起见，我将跳过详细信息，仅向您展示 TPS（每秒事务数）结果。

结果和总结

在一对 AWS EC2 i2.xlarge 实例上（对于繁忙的应用程序来说，这是一个很好的起点，因为它的 I/O 已优化，4 个 vCPU，30.5 GB RAM，800 GB SSD），我设置“pgbench”的比例因子为100，并发会话数为8，进行了10分钟的测试，得到了以下数字：

“on” 异步 – 4256 TPS（仅供参考——这里 1 个事务意味着 3 个更新、1 个插入、1 个查询）

“off”异步– 6211 TPS（与默认的“异步on”相比增加 45%）

“on”同步– 3329 TPS（与默认的“异步on”相比降低 22% ）

“remote_write”同步– 3720 TPS（与“同步on”相比增加 12%）

“remote_apply”同步– 3055 TPS（与“同步on”相比降低 8% ）

首先，一如既往 - 性能数字取决于很多东西，尤其是对于同步复制会受到网络性能/距离的影响，所以不同测试环境的测试结果肯定会有所不同，但我认为我们仍然可以从这里注意到一些事情：

• 通过关闭“synchronous_commit”，您可以获得非常显着的 TPS 提升，它确实可以用作临时性能支持
• 进行同步复制时，您将损失大约 1/4 的性能
• 当进行同步复制时，“remote_apply”和默认的“on”之间的差异小于 10%，因此如果在性能方面还没有达到极限，并且还使用副本进行读取查询，那么启用这种最安全的设置以获得数据的镜像视图是有意义的。