如果我们比较多种类型的复制(单领导、多领导或无领导)，单领导复制有可能是线性化的。在我的理解中，线性化意味着一旦写入完成，所有以后的读取都应该返回该值，或者稍后的写入。或者换句话说，如果只有一个数据库，而不是更多，应该有一个印象。所以我想，没有陈旧的阅读。
PostgreSQL 在他的流复制中，能够使用synchronous_standby_names使其所有副本同步，并且还能够使用synchronous_commit选项进行微调，在该选项中它可以设置为remote_apply，因此领导者会等到事务在备用数据库上重放(使其对查询可见)。在文档中，在讨论remote_apply选项的段落中，它指出这允许在简单情况下进行负载平衡，并具有因果一致性。
几页后，它说：
，，某些解决方案是同步的，这意味着在所有服务器提交事务之前，不会认为已提交数据修改事务。这保证了故障转移不会丢失任何数据，并且无论查询哪个服务器，所有负载平衡的服务器都将返回一致的结果，
所以我正在努力理解可以保证什么，以及如果我们对只读副本的读取查询进行负载平衡，会发生什么异常。还能有过时的阅读吗？当我查询不同的副本以获得不同的结果时，即使领导者发生后没有写入，也会发生这种情况吗？我的印象是肯定的，但我不太确定。 如果不是，PostgreSQL 如何防止过时的读取？我没有找到任何更详细的信息，它是如何在引擎盖下完全工作的。它是否使用两阶段提交，或对其进行一些修改，或者它使用其他算法来防止过时的读取？
如果它不提供无过时读取的选项，有没有办法做到这一点？我看到，PgPool 必须选择对不超过定义阈值的副本进行负载平衡，但我不明白是否可以将其定义为对与领导者相关的副本进行负载平衡。
真正理解在PostgreSQL中的完全同步复制中是否会发生异常，这对我来说真的很困惑。
我知道这样的设置存在可用性问题，但现在这不是问题。
如果对synchronous_commit = remote_apply使用同步复制，则可以确定一旦修改事务提交，您将在备用数据库上看到修改后的数据。
同步复制不使用两阶段提交，主服务器首先在本地提交，然后简单地等待同步备用服务器的反馈，然后再返回COMMIT。因此，可以执行以下操作：
观察者将在
COMMIT返回之前以及将数据传播到备用数据库之前在主数据库上看到修改后的数据。观察者将在主数据库返回
COMMIT之前在备用数据库上看到修改后的数据。如果提交事务在返回之前的适当时刻在主服务器上中断
COMMIT则事务将仅在主服务器上提交。在服务器上进行提交的时间与向客户端报告提交的时间之间始终存在特定的时间窗口，但该窗口会随着流式复制而大大增加。但是，最终，数据修改将始终进入备用状态。