Patroni在主库物理死机后可自动Failover，但“优雅安全”取决于DCS可达性、备库同步状态及postgresql.conf中复制参数配置合理性；RPO由切换前WAL同步状态决定，而非自动切换本身。
主库物理死机后，Patroni 能自动完成 Failover，但“优雅安全”不取决于 Patroni 是否启动，而取决于你是否提前规避了三个硬性前提失效：DCS 可达性、备库同步状态、以及 postgresql.conf 中关键复制参数的配置合理性。自动切换本身不保证数据不丢，只保证服务能续；真正决定 RPO 的，是切换前最后一刻的 WAL 同步状态。
DCS 必须独立存活且心跳未超时
Patroni 不靠节点间通信选主，而是依赖 DCS（如 etcd/Consul/ZooKeeper）做分布式锁和状态广播。主库物理死机后，Patroni 进程自然退出，但只要 DCS 本身没挂、网络通、会话 TTL 未过期，其他节点就能感知 leader 缺失并发起选举。
-
session.TTL建议设为 30s，对应 Patroni 配置中ttl和loop_wait需匹配（例如ttl: 30,loop_wait: 10），否则可能因心跳断连误判为脑裂 - 检查 DCS 网络连通性：在备节点执行
curl -s http://etcd:2379/health | jq .health，返回"true"才算可用 - 避免把 DCS 和 PostgreSQL 部署在同一台物理机上——主库死机时若 DCS 也跟着宕，整个集群将卡在“无主可选”状态，无法自动 Failover
备库必须处于 streaming + sync 或 potential_sync 状态
Patroni 默认只允许 streaming 状态的备库参与选举；如果备库 WAL 落后太多（比如延迟 > maximum_lag_on_failover 阈值，默认 1048576 字节 ≈ 1MB），它会被跳过，哪怕它是唯一存活节点。
- 确认同步状态：登录备库运行
pg_stat_replication，关注state（应为streaming）、sync_state（sync/potential最佳）、replay_lsn与主库pg_current_wal_lsn()差值 - 调整阈值：在 Patroni 配置的
postgresql段下显式设置maximum_lag_on_failover: 10485760（10MB），防止因瞬时网络抖动导致备库被排除 - 物理死机前若主库已卡住 WAL 发送（
pg_stat_replication.sent_lsn = pg_stat_replication.write_lsn且长时间不变），说明复制链路早中断，此时 Failover 必丢数据——这问题得靠监控提前发现，不是切换时能补救的
Failover 后应用连接必须绕过旧主地址
Patroni 完成 Failover 后，新主已就位，但旧主 IP 仍可能响应 TCP 连接请求（尤其当它只是“假死”、系统未彻底断电），导致应用连上一个只读、不可写、甚至正在自愈重启的实例。
- 绝对不要直接用 PostgreSQL 节点 IP 做应用连接串；必须前置一层流量路由层，如
HAProxy或pgbouncer，并配置健康检查指向 Patroni 的 REST API（http://node:8008/health返回{"state": "running", "role": "master"}才转发） - Patroni 自身不修改 DNS 或 VIP；如果你用 keepalived 绑 VIP，请确保其 healthcheck 脚本调用
patronictl -c patroni.yml list并严格校验Role字段，而不是只 ping 端口 - 应用侧需支持连接重试（如 JDBC 的
reWriteBatchedInserts=true&connectTimeout=5），避免在切换窗口期因连接拒绝直接报错退出
最易被忽略的一点：Patroni 的 retry_timeout 和 standby_cluster 配置项，在物理死机场景下几乎不起作用——它们针对的是主库进程僵死但 OS 仍在响应的软故障。真到电源灯灭的那一刻，唯一起效的是 DCS 的会话超时机制和备库的 WAL 实时性。别信“自动=零数据丢失”，先看你的 max_wal_size、archive_timeout 和备库 recovery_min_apply_delay 是怎么配的。
