Hans-Juergen Schoenig：PostgreSQL高可用架构
内容提要
PostgreSQL高可用推荐Patroni集群实现自动故障转移，通过etcd达成共识。应用可用多主机连接串、vip-manager或haproxy定位主库。跨数据中心可用standby集群，但需第三站点做多数决策。active-active因异步复制易冲突且不加速写入，仅少数无冲突场景适用，95%情况推荐单主架构。
延伸解读
应用如何找到主库：三种连接方案对比
文章介绍了三种让应用定位主库的方法：多主机连接串、vip-manager 和 haproxy。多主机连接串将集群所有节点信息交给应用，由驱动根据目标会话属性选择主库，适合基于 libpq 的语言；vip-manager 通过浮动 IP 对应用透明，但需要管理 IP 的能力；haproxy 可路由到主库，但会增加网络跳数，可能影响大量小语句的延迟。选择时需权衡应用改造、网络开销和运维复杂度。
跨数据中心部署：为何需要第三站点
当集群跨两个数据中心时，Patroni 可配置 standby 集群，整个集群跟随另一个集群。若主数据中心整体故障，可手动提升备数据中心。但文章强调，两个数据中心无法形成多数决策，因此需要第三站点（如单个 VM 或完整数据中心）来达成共识。这增加了硬件成本，但对航空管制、应急服务等极端关键场景可能是必要的。
active-active 的复制冲突与写入瓶颈
文章以银行取款为例说明 active-active 的复制冲突：两个节点同时扣减同一账户，异步复制导致双方都提交，最终余额错误。由于跨地域同步锁开销极大，所有长距离方案都依赖异步复制，冲突难以避免。此外，active-active 不会加速写入，因为每个节点仍需写入全部数据；写入只能通过分片扩展。因此，95% 的场景推荐单主架构。
active-active 的适用场景与结构变更风险
active-active 仅在少数无冲突场景中适用，例如不同地域的员工各自修改本地区数据，冲突概率设计为零。但结构变更（如增删列）在链路故障时可能导致不一致，通常需要停机维护。文章提醒，虽然 active-passive 也有类似问题，但 active-active 的复杂度和惩罚更高。在采用前应仔细评估业务冲突模式和运维能力。
Q&A
PostgreSQL 高可用架构中，如何实现自动故障转移？
使用 Patroni 集群，它基于 etcd 实现分布式共识，能够自动进行故障转移和数据库恢复。
在 PostgreSQL 集群中，应用如何找到主库？
有三种常见方法：1. 多主机连接串，应用配置所有节点，通过驱动选择主库；2. vip-manager，使用浮动 IP 指向主库；3. haproxy，在每个节点运行，自动路由到主库。
为什么不能简单地让数据库自动区分读写查询？
因为仅通过解析 SQL 语句无法确定是读还是写，例如包含函数的查询可能在运行时才决定读写，因此中间件无法可靠区分。
跨数据中心的 PostgreSQL 高可用架构如何设计？
可以配置 standby 集群，即一个集群跟随另一个集群。如果主数据中心故障，可以手动提升备用数据中心。但需要第三个站点（如单个 VM 或完整数据中心）来做出多数决策。
active-active 架构在 PostgreSQL 中有什么主要问题？
主要问题是复制冲突，由于异步复制，可能导致数据不一致（如双倍取款示例）。此外，它不会加速写入，因为每个节点仍需写入所有数据，且数据结构变更困难，可能造成停机。
在什么情况下 active-active 架构可能适用？
在无冲突的场景下可能适用，例如不同区域只修改各自的数据，冲突概率设计为 0。但 95% 的情况下推荐单主架构。
