在阅读了PgPool的文档后，我不知道哪个选项最适合我的用例。我需要一个主数据库实例来提供查询服务，以及用于灾难恢复场景的主数据库的一个或多个副本(备用(。对我来说非常重要的是，所有成功提交到主节点的事务都保证最终复制到副本，这样，当发生故障转移时，副本数据库实例的所有事务都会应用到它，包括最新的事务。
在异步复制方面，我在PgPool文档中没有看到任何提及是否存在这种情况，但是，它确实提到了一些潜在的数据丢失，这对我来说有点太模糊了，无法得出任何结论。
为了防止这种数据丢失，文档建议使用同步流复制，在主节点中提交事务之前，确保所有副本也应用了该更改。因此，这种方法比异步方法慢，但如果没有数据丢失，它可能是可行的。
同步复制是唯一允许我实现用例的方法吗？还是异步复制也能做到这一点？此外，异步复制中潜在的数据丢失是由什么构成的？
异步复制意味着主服务器在向客户端报告成功的COMMIT之前不会等待备用服务器。因此，如果主服务器出现故障，则客户端可能认为某个事务已提交，但没有一个备用服务器接收到WAL信息。在高可用性设置中，在主服务器丢失的情况下升级备用服务器，这意味着您可能会丢失已提交的事务，尽管信息通常只需要一瞬间就可以到达备用服务器。
使用同步复制，主服务器等待，直到第一个可用的同步备用服务器报告它已经接收并保持WAL信息，然后向客户端报告成功的CCD_。因此，即使主服务器永远不存在，也不会丢失已报告提交给客户端的任何事务。
虽然配置同步复制在技术上很简单，但它带来了架构和设计问题，因此异步复制通常是更好的选择：
-
同步复制大大降低了所有数据修改的速度。要想正常工作，主设备和备用设备之间的网络延迟必须非常低。您通常无法合理地在不同的数据中心之间使用同步复制。
-
同步复制降低了整个系统的可用性，因为备用服务器的故障会阻止任何数据修改的成功。因此，您需要至少有两个同步备用服务器，一个保持同步，另一个作为备用服务器。
-
即使使用同步复制，也不能保证在向主服务器写入数据后从备用服务器读取数据会为您提供新数据，因为默认情况下，主服务器不会等待WAL在备用服务器上重播。如果需要，则需要在主服务器上设置
synchronous_commit = remote_apply。但是，由于在待机状态下的查询可能与WAL重播冲突，您将不得不处理复制(和提交(延迟或在待机状态上取消查询。因此，只有当您能够处理在待机状态下无法立即看到的数据修改时，才有可能使用同步复制作为水平扩展的工具。