杰里米·施奈德：解释IPC：同步复制 - Postgres同步复制实际上并非真正的同步复制
💡
原文英文，约800词，阅读约需3分钟。
📝
内容提要
Postgres数据库的同步复制实际上是异步的，只有在客户端提交时才会暂停，导致性能波动。大批量操作会产生大量WAL，可能导致其他操作延迟。建议监控WAL活动并调整相关参数以减轻影响。
🎯
关键要点
-
Postgres数据库的同步复制实际上是异步的，只有在客户端提交时才会暂停。
-
大批量操作会产生大量WAL，可能导致其他操作延迟。
-
建议监控WAL活动并调整相关参数以减轻影响。
-
WAL存储需求会随着复制流的滞后而增加，难以预测所需的存储空间。
-
存储级同步复制与数据库级同步复制有所不同，后者在写入时会立即fsync整个WAL流。
-
小型短事务的工作负载下，Postgres数据库级复制表现良好，但大批量操作会导致问题。
-
autovacuum_vacuum_cost_delay为零可能导致WAL生成过多，造成混乱。
-
建议分析WAL活动以调试IPC:SyncRep等待事件。
-
可以考虑在Postgres的vacuum和其他操作中添加代码，以根据synchronous_commit参数定期暂停。
-
建议开发监控查询，以区分单个连接与多个写入连接对WAL流的影响。
❓
延伸问答
Postgres的同步复制实际上是什么样的？
Postgres的同步复制实际上是异步的，只有在客户端提交时才会暂停。
大批量操作对Postgres数据库有什么影响？
大批量操作会生成大量WAL，可能导致其他操作延迟，影响性能。
如何监控Postgres的WAL活动？
建议分析WAL活动并使用监控查询来调试IPC:SyncRep等待事件。
为什么autovacuum_vacuum_cost_delay为零是个坏主意？
因为它会导致VACUUM以全速运行，生成大量WAL，造成系统混乱。
Postgres的存储级同步复制与数据库级同步复制有什么不同？
存储级同步复制需要每个写入操作都被复制，而数据库级同步复制在提交时才fsync整个WAL流。
如何减轻Postgres同步复制带来的性能波动？
可以考虑在VACUUM和其他操作中添加代码，根据synchronous_commit参数定期暂停。
➡️
