同步复制模式的三重真实代价：性能、可用性、方案成熟度

PostgreSQL在两节点场景下推荐使用异步（async）复制，但并不是不支持同步（sync）复制——即使只有两个节点，同步复制也是可以配置的，只是它会带来三个层面的真实代价。第一是性能代价：同步模式要求主库必须等到从库把数据真正写入成功之后，才能结束这次事务的Commit操作，这意味着每一次写操作的响应时间都要包含一次跨节点的网络往返和从库落盘的耗时，相比异步模式（主库写完本地就可以立刻返回）性能会明显受到影响。第二是可用性代价：如果从库在系统运行过程中出现故障，因为主库的每次提交都依赖从库确认，主库也会跟着一起受影响，进而导致整个系统出现故障，甚至在HA架构下触发不必要的Failover——这意味着同步复制把从库的可用性和主库的可用性绑定在了一起，从库单点故障的影响范围被放大到了整个系统，而当时Pacemaker最新的PostgreSQL资源代理（RA）还没有解决这个问题。第三是方案成熟度代价：如果确实需要用同步模式的流复制，更推荐的是一主两备的三节点模型（写入只需要两个节点成功、第三个节点异步即可返回，兼顾一定的性能和可靠性），但这个三节点模型当时Pacemaker还没有提供现成的实现方案，需要额外投入去补齐。这三重代价共同说明：同步复制并不是一个”打开开关就能获得更强一致性、没有其他副作用”的简单选项，它在响应延迟、故障影响范围、配套工具成熟度这三个维度上都要求使用者做出额外的权衡和投入——这提示了一条评估任何”强一致性”选项的通用原则：越强的一致性保证，通常意味着系统对参与节点的可用性要求也越苛刻（任何一个相关节点出问题都可能拖累整体），评估要不要启用某种强一致性模式时，必须把这种”依赖关系被绑得更紧”的连带风险，和它带来的一致性收益放在一起权衡，而不能只看到”数据更安全”这一个正面维度。