使用 PgPool 进行 Postgres 的同步与异步流复制

Question

阅读 PgPool 的文档后，我很困惑哪个选项最适合我的用例。我需要一个主数据库实例来服务查询，以及主数据库实例的 1 个或多个副本（备用）用于灾难恢复场景。对我来说非常重要的是，所有成功提交到主节点的事务都保证最终被复制到副本，这样当发生故障转移时，副本数据库实例将拥有直到并包括应用于其的最新事务的所有事务。

在异步复制方面，我在 PgPool 文档中没有看到任何提及是否是这种情况，但是，它确实提到了一些潜在的数据丢失，这对我来说有点太模糊了，无法得出任何结论。

为了防止这种数据丢失，文档建议使用同步流复制，在主节点中提交事务之前，确保所有副本也应用了该更改。因此，这种方法比异步方法慢，但如果没有数据丢失，它是可行的。

同步复制是允许我实现用例的唯一方法吗？还是异步复制也可以实现这一点？另外，异步复制中潜在的数据丢失是什么构成的？

Answer 1

异步复制COMMIT意味着主服务器在向客户端报告成功之前不会等待备用服务器。因此，如果主服务器发生故障，客户端可能认为某个事务已提交，但备用服务器还没有收到 WAL 信息。在高可用性设置中，如果主服务器丢失，则升级备用服务器，这意味着您可能会丢失已提交的事务，尽管信息通常只需要一瞬间即可到达备用服务器。

使用同步复制，主服务器会等待，直到第一个可用的同步备用服务器报告它已收到并持久化 WAL 信息，然后再向COMMIT客户端报告成功（详细信息，例如选择了哪个备用服务器，其中有多少个备用服务器）报告并确定备用数据库接收到的 WAL 计数何时可配置）。因此，即使主服务器永久消失，已报告提交给客户端的事务也不会丢失。

虽然配置同步复制在技术上很简单，但它带来了架构和设计问题，因此异步复制通常是更好的选择：

• 同步复制大大减慢了所有数据修改的速度。为了正常工作，主数据库和备用数据库之间的网络延迟必须非常低。您通常无法合理地使用不同数据中心之间的同步复制。

• 同步复制会降低整个系统的可用性，因为备用服务器的故障会阻止任何数据修改成功。因此，您需要至少有两台同步备用服务器，一台保持同步，一台作为替代服务器。

• 即使使用同步复制，也不能保证在写入主数据库后从备用数据库读取数据会提供新数据，因为默认情况下主数据库不会等待在备用数据库上重播 WAL。如果你想要这样，你需要synchronous_commit = remote_apply在主服务器上进行设置。但由于备用数据库上的查询可能与 WAL 重播发生冲突，因此您必须处理复制（和提交）延迟或备用数据库上取消的查询。因此，只有当您能够处理在备用数据库上不立即可见的数据修改时，才可以合理地使用同步复制作为水平扩展的工具。