带有 PgPool 的 Postgres 的同步与异步流复制

Question

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

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

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

同步复制是允许我实现用例的唯一方法还是异步复制也能解决问题？ 另外，异步复制中潜在的数据丢失是什么？

Answer 1

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

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

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

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

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

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