20 狡兔三窟：高可用拓扑与容灾目标

三台 PostgreSQL 都在运行，不等于“高可用”；一次 patronictl list 显示一个 Leader，也不等于“不会脑裂”；计划切换没有丢行，更不等于 “自动故障转移零 RPO”。

本章把高可用收敛为一个可以审计的命题：

在明确的失败模型、提交语义与权限边界内，系统能否维持一条被授权的可写历史，并在规定时间内把客户端带回可判断的服务状态？

我们先从 failure model、RPO/RTO 和 degradation target 出发，再进入 PostgreSQL 的 WAL、LSN、timeline、复制槽与同步提交；随后解释 Patroni、 DCS、租约与 fencing 如何组合；最后在第 19 章保留的 Pigsty v4.5.0 四机沙箱上完成一次有客户端证据的计划切换。

本章的正式结论很克制：

健康计划切换             通过，带十项沙箱例外
自动故障转移             未测试
硬件/进程/网络故障       未注入
零 RPO                   未证明
生产 RTO                 未证明
fencing / watchdog       未验收
生产批准                  pending

本章目标

读完并完成实验后，你应当能够：

先列故障域和共同依赖，再谈节点数与“几副本”；
正确区分 RPO、RTO、降级目标、维护切换时间与客户端恢复时间；
从 pg_stat_replication、pg_stat_wal_receiver、LSN 与复制槽解释物理流复制；
区分 system identifier、timeline、checkpoint timeline 与当前 WAL timeline；
解释异步、remote_write、on、remote_apply 以及 FIRST/ANY 同步集合的保证和代价；
说明 Patroni leader lock、DCS、TTL、loop、candidate eligibility、 watchdog 与 fencing 分别解决什么问题；
区分 planned switchover、automatic/manual failover、rewind 与 rebuild；
把服务端点、会话断开、结果未知与幂等 token 放在同一个客户端合同中；
用 Pigsty 交付的角色、服务与原生 PostgreSQL 证据交叉验证；
设计一场有 preflight、mutation guard、证据、反例和复位的 HA 演练；
知道一次成功实验不能推出哪些生产结论。

前置与后续

前置：

第 18 章 PostgreSQL 数据平台与替代边界定义 service objective 与 capability placement；
第 19 章部署基线保留四台独立 VM、两个 PostgreSQL service unit 以及 secret-safe inventory；
读者已掌握 Linux、SQL、事务与基本网络知识；
不要求预先掌握 Patroni、etcd 或 Pigsty HA internals。

后续：

第 21 章备份体系与恢复演练处理 base backup、WAL archive、 PITR 与 restore proof；
第 22 章服务接入、连接池与路由深入 routing、 pooling、session 与 client retry contract；
第 23 章处理 transport、identity 与 secret；
第 33 章才安排另行授权的 unplanned failure/incident exercise。

学习路径

business loss
  -> failure model + common dependencies
      -> RPO / RTO / degradation contract
          -> WAL transport + replay + timeline
              -> commit acknowledgement policy
                  -> election authority + fencing
                      -> service routing + client semantics
                          -> guarded planned switchover
                              -> evidence + exceptions + next gate

这条路径故意不从“如何敲 failover 命令”开始。命令只是状态迁移的一个触发器；如果故障、authority、数据风险与客户端完成条件没有先定义，操作越快，越可能把错误历史更快地交给用户。

正式实验拓扑

target       pg36-l2-vagrant/pg-test
Pigsty       exact v4.5.0 tag
PostgreSQL   18.6
Patroni      4.1.3
DCS          one etcd member (sandbox exception)
members      pg-test-1 / pg-test-2 / pg-test-3
policy       asynchronous; synchronous_mode=false
watchdog     off (sandbox exception)
client       Pigsty primary service, 10.10.10.11:5433

角色迁移：

before          pg-test-1 primary, pg-test-2/3 streaming, timeline 5
forward         pg-test-2 primary, pg-test-1/3 streaming, timeline 6
restored        pg-test-1 primary, pg-test-2/3 streaming, timeline 7
lineage         one unchanged PostgreSQL system identifier

实验通过 Pigsty primary service 写入唯一 token，而不是直接连接“我们以为是主库”的节点。正式观测：

probe attempts                    120
acknowledged                       95
outcome unknown                    25
acknowledged rows missing           0
unknown committed                   0
unknown reconciled absent          25
duplicate tokens                    0
forward patronictl command      2.735 s
forward action to stable        5.823 s
conservative sampled write gap  6.007 s

6.007 s 是一次健康计划切换下的采样写入间隙。它包含约 0.2 秒的 probe resolution，不包含故障检测，不是生产 RTO 分布，也不是 SLO。

十项例外

沿用第 19 章六项：

EX19-SHARED-HYPERVISOR
EX19-SINGLE-ETCD
EX19-SINGLE-BACKUP-TARGET
EX19-VIRTUAL-STORAGE
EX19-INVENTORY-SECRETS
EX19-LAB-RESOURCE-FLOOR

本章新增四项：

EX20-ASYNC-BASELINE
  synchronous_mode=false；不能声称 zero RPO

EX20-WATCHDOG-OFF
  未验证硬件 watchdog fencing

EX20-CLIENT-PROXY-NO-TLS
  沙箱外部 5433 只以 sslmode=prefer 验证；不能通过生产传输安全

EX20-PLANNED-ONLY
  只做 healthy switchover；不能声称 automatic failover、split-brain
  exclusion 或 failure-time RTO

例外不是“以后再看”的备注，而是直接阻止某类推论的逻辑条件。

实验入口

lab-contract.md：动作、风险和解释边界；
requirements.json：可执行验收合同；
failure-model.json：九类场景；
ha-adr.md：为什么只接受 planned switchover；
task.sh：安全动作入口；
ha-facts.sql：PostgreSQL 原生证据；
drill-run.json：无 secret 的正式结果；
negative-cases.json：十个必须拒绝的反例；
topology.mmd：实验数据与控制路径。

安全语义：

capture / verify / review / all
  L0 read-only

drill:switchover
  L2 local sandbox mutation
  exact target + no production data/traffic + explicit confirmation

reset:fixture
  destructive and separate
  never called by all or drill:switchover

普通 all 只验证已有证据。它不会为了“方便”重跑切换。

本章最重要的判断

replica exists             != RPO achieved
three nodes                != three failure domains
leader elected             != old primary fenced
Patroni healthy            != client service recovered
command returned           != application RTO
connection error           != transaction rolled back
planned switchover passed  != unplanned failover passed
no missing ack in one run  != asynchronous zero RPO
HA                         != backup / PITR

如果只记住一句话：

高可用的目标不是“尽快出现一个新主库”，而是在故障与不确定性中，只让一条可解释、可追溯、被授权的历史继续接受写入。

权威参考

上一章：开天辟地：环境规划与部署基线 · 返回下卷导读 · 下一章：未雨绸缪：备份体系与恢复演练 · 查看全书目录 · 查看索引中心

20 狡兔三窟：高可用拓扑与容灾目标

本章目标

前置与后续

学习路径

正式实验拓扑

十项例外

本章目录

20.1 从失败模型设计高可用

20.2 物理流复制

20.3 同步策略与提交语义

20.4 选主、DCS 与防脑裂

20.5 切换、故障转移与重加入

20.6 交付并观察 HA 集群

20.7 实战：一次有证据的计划切换

实验入口

本章最重要的判断

权威参考

从失败模型设计高可用

物理流复制

同步策略与提交语义

选主、DCS 与防脑裂

切换、故障转移与重加入

交付并观察 HA 集群

实战：一次有证据的计划切换