PostgreSQL 高可用3 种故障转移方案怎么选【免费下载链接】awesome-postgresA curated list of awesome PostgreSQL software, libraries, tools and resources, inspired by awesome-mysql项目地址: https://gitcode.com/gh_mirrors/aw/awesome-postgres本文解决一个问题PostgreSQL 主库宕机后如何把流量以最小停机切到备库。以 awesome-postgres 生态里的故障转移工具为参照讲清工具选型对比、Patroni 自动切换全流程、手动主从切换清单以及监控与演练节奏。面向 DBA 与后端开发者读完能选对工具并跑通一次真实切换演练。主库宕机时的业务代价凌晨三点主库进程挂掉或者磁盘写满。若备库没有被提升所有写请求堆在连接池里事务日志停止推进上游服务开始成批返回 5xx——应用已经半死。宕机时间每多一分钟投诉与 SLA 赔付就多一分。唯一的出路是把流量切到健康备库用哪个工具、如何判定主库真的死了、怎么避免两个节点都自认为是主库脑裂是本文逐一拆解的问题。工具选型Patroni / repmgr / pg_auto_failover 对比awesome-postgres 的 High-Availability 板块中三者最具代表性完整工具清单见 README.md维度Patronirepmgrpg_auto_failover共识组件依赖依赖 etcd / Consul / ZooKeeper 等 DCS无用独立管理库无内置监控服务自动切换能力自动DCS 锁防脑裂repmgrd 自动监控需调参自动由服务进程监控部署复杂度较高需先搭 DCS 集群中等命令直观低装扩展加服务即可适用场景K8s / 多节点生产集群要求流程可控可审计的团队配置最少的小中集群结论环境里已有 etcd 或跑在 K8s 上选 Patroni其 DCS 锁是防脑裂最可靠的机制不能接受任何外部组件从 pg_auto_failover 起步全程只需要一个监控服务repmgr 适合手动为主、自动兜底的团队命令集最透明切换过程便于理解和审计。Patroni 自动故障切换的五步走读第一步 故障发生怎么判断主库停止接受连接、WAL 生成停止。别立刻下结论——瞬时网络分区看起来也一样判定条件是进程或端口不可达并等健康检查确认。第二步 健康检查判定ttl 与 loop_wait 怎么设Patroni 主库在 DCS 里持有 leader 键需在ttl默认 30 秒内刷新检查周期由loop_wait控制。判定条件超过一个loop_wait周期仍未刷新其余节点判定主库失联。业务敏感时把loop_wait缩到 10 秒代价是抖动期误报增多。第三步 提升备库锁决定谁上位备库节点竞争 DCS 的 master 锁先拿到锁的才执行 promote。判定条件成功拿锁且相对旧主 WAL 位点LSN的复制延迟在阈值内落后的节点主动放弃本轮。第四步 客户端重连应用侧探测到连接错误后自动重试通过集群名或连接池解析新主地址配合 PgBouncer 可让切换对应用透明。判定条件新主pg_is_in_recovery()返回 false读写冒烟通过。第五步 原主回归旧主恢复后由 Patroni 以备库模式重启回放缺失的 WAL。判定条件旧主启动后处于 recovery 状态与新主的复制恢复正常且延迟追平。Patroni 关键配置与检查命令postgresql: parameters: synchronous_commit: remote_apply restapi: listen: 0.0.0.0:8008 etcd3: hosts: etcd1.internal:2379,etcd2.internal:2379切换后执行一条命令确认各节点角色patronictl list手动主从切换清单切换前 / 中 / 后没有自动化工具的团队按以下清单推进切换切换前确认主库无法恢复记录时间与故障现象核对备库pg_is_in_recovery()为 true复制延迟在可接受范围冻结应用写入停连接池或置只读降低不一致风险记录备库当前 WAL 位点LSN便于事后比对切换中在备库执行提升为主库recovery.signal pg_promote或 repmgr standby promote提升后确认可读可写把客户端连接串 / VIP / DNS 指向新主切换后恢复应用流量做读写冒烟测试原主重建为新主的备库验证复制追平更新监控对象与告警规则归档切换日志与 LSN 记录留作审计三个常见坑脑裂、数据不一致、连接失败脑裂两个主库同时接受写入现象新旧主库事务序列各走各的应用侧数据消失。根因网络分区让旧主以为仍存活备库又被提升缺乏锁阻止双主。对策依赖 DCS 分布式锁或人工确认仲裁后再提升核心业务用同步复制保证备库数据完整。数据不一致新主丢最近事务现象切换后查询最近几条写入查不到。根因被提升的备库 LSN 落后旧主异步复制的最后几个事务丢失。对策核心表开同步复制日常监控复制延迟超 5 秒即告警关键数据切换前先核对。应用连接失败切换后不恢复现象新主库正常应用却持续抛连接错误。根因应用写死旧主地址连接池挂着失效连接且未配置自动重连。对策PgBouncer 前置让应用透明重连应用侧开启带退避的重试服务发现指向集群名而非固定 IP。监控指标与演练节奏指标含义阈值建议复制延迟备库 WAL 回放落后量超 5 秒告警超 30 秒红色WAL 生成速率主库每秒 WAL 产出偏离基线 3 倍排查写入异常主库连接探测端口与健康检查成功率连续 3 次失败即告警WAL 磁盘剩余空间归档与预写日志容量剩余低于 20% 告警缓冲命中 / 内存buffer cache 命中率低于 90% 需排查演练节奏月度计划内窗口做一次主从切换演练验证应用自动重连链路季度kill 主库模拟真实故障验证自动故障切换的耗时与正确性年度全流程灾难恢复演练含原主回归与数据校验收个尾故障转移工具只是高可用的一半另一半是监控数据与演练记录。先选一个与团队运维水平匹配的工具在测试环境跑通第一次切换。让切换成为可验证的流程下一次真实故障才会只是告警日志里的一行记录。⚠️ 生产变更提醒任何故障转移方案先在测试环境验证并在业务低峰期执行动手前备好回滚预案VIP 回切、连接串回退、原主恢复步骤。【免费下载链接】awesome-postgresA curated list of awesome PostgreSQL software, libraries, tools and resources, inspired by awesome-mysql项目地址: https://gitcode.com/gh_mirrors/aw/awesome-postgres创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/11/4 11:11:57 · 阅读 1.2k PostgreSQL 高可用：3 种故障转移方案怎么选？
PostgreSQL 高可用3 种故障转移方案怎么选【免费下载链接】awesome-postgresA curated list of awesome PostgreSQL software, libraries, tools and resources, inspired by awesome-mysql项目地址: https://gitcode.com/gh_mirrors/aw/awesome-postgres本文解决一个问题PostgreSQL 主库宕机后如何把流量以最小停机切到备库。以 awesome-postgres 生态里的故障转移工具为参照讲清工具选型对比、Patroni 自动切换全流程、手动主从切换清单以及监控与演练节奏。面向 DBA 与后端开发者读完能选对工具并跑通一次真实切换演练。主库宕机时的业务代价凌晨三点主库进程挂掉或者磁盘写满。若备库没有被提升所有写请求堆在连接池里事务日志停止推进上游服务开始成批返回 5xx——应用已经半死。宕机时间每多一分钟投诉与 SLA 赔付就多一分。唯一的出路是把流量切到健康备库用哪个工具、如何判定主库真的死了、怎么避免两个节点都自认为是主库脑裂是本文逐一拆解的问题。工具选型Patroni / repmgr / pg_auto_failover 对比awesome-postgres 的 High-Availability 板块中三者最具代表性完整工具清单见 README.md维度Patronirepmgrpg_auto_failover共识组件依赖依赖 etcd / Consul / ZooKeeper 等 DCS无用独立管理库无内置监控服务自动切换能力自动DCS 锁防脑裂repmgrd 自动监控需调参自动由服务进程监控部署复杂度较高需先搭 DCS 集群中等命令直观低装扩展加服务即可适用场景K8s / 多节点生产集群要求流程可控可审计的团队配置最少的小中集群结论环境里已有 etcd 或跑在 K8s 上选 Patroni其 DCS 锁是防脑裂最可靠的机制不能接受任何外部组件从 pg_auto_failover 起步全程只需要一个监控服务repmgr 适合手动为主、自动兜底的团队命令集最透明切换过程便于理解和审计。Patroni 自动故障切换的五步走读第一步 故障发生怎么判断主库停止接受连接、WAL 生成停止。别立刻下结论——瞬时网络分区看起来也一样判定条件是进程或端口不可达并等健康检查确认。第二步 健康检查判定ttl 与 loop_wait 怎么设Patroni 主库在 DCS 里持有 leader 键需在ttl默认 30 秒内刷新检查周期由loop_wait控制。判定条件超过一个loop_wait周期仍未刷新其余节点判定主库失联。业务敏感时把loop_wait缩到 10 秒代价是抖动期误报增多。第三步 提升备库锁决定谁上位备库节点竞争 DCS 的 master 锁先拿到锁的才执行 promote。判定条件成功拿锁且相对旧主 WAL 位点LSN的复制延迟在阈值内落后的节点主动放弃本轮。第四步 客户端重连应用侧探测到连接错误后自动重试通过集群名或连接池解析新主地址配合 PgBouncer 可让切换对应用透明。判定条件新主pg_is_in_recovery()返回 false读写冒烟通过。第五步 原主回归旧主恢复后由 Patroni 以备库模式重启回放缺失的 WAL。判定条件旧主启动后处于 recovery 状态与新主的复制恢复正常且延迟追平。Patroni 关键配置与检查命令postgresql: parameters: synchronous_commit: remote_apply restapi: listen: 0.0.0.0:8008 etcd3: hosts: etcd1.internal:2379,etcd2.internal:2379切换后执行一条命令确认各节点角色patronictl list手动主从切换清单切换前 / 中 / 后没有自动化工具的团队按以下清单推进切换切换前确认主库无法恢复记录时间与故障现象核对备库pg_is_in_recovery()为 true复制延迟在可接受范围冻结应用写入停连接池或置只读降低不一致风险记录备库当前 WAL 位点LSN便于事后比对切换中在备库执行提升为主库recovery.signal pg_promote或 repmgr standby promote提升后确认可读可写把客户端连接串 / VIP / DNS 指向新主切换后恢复应用流量做读写冒烟测试原主重建为新主的备库验证复制追平更新监控对象与告警规则归档切换日志与 LSN 记录留作审计三个常见坑脑裂、数据不一致、连接失败脑裂两个主库同时接受写入现象新旧主库事务序列各走各的应用侧数据消失。根因网络分区让旧主以为仍存活备库又被提升缺乏锁阻止双主。对策依赖 DCS 分布式锁或人工确认仲裁后再提升核心业务用同步复制保证备库数据完整。数据不一致新主丢最近事务现象切换后查询最近几条写入查不到。根因被提升的备库 LSN 落后旧主异步复制的最后几个事务丢失。对策核心表开同步复制日常监控复制延迟超 5 秒即告警关键数据切换前先核对。应用连接失败切换后不恢复现象新主库正常应用却持续抛连接错误。根因应用写死旧主地址连接池挂着失效连接且未配置自动重连。对策PgBouncer 前置让应用透明重连应用侧开启带退避的重试服务发现指向集群名而非固定 IP。监控指标与演练节奏指标含义阈值建议复制延迟备库 WAL 回放落后量超 5 秒告警超 30 秒红色WAL 生成速率主库每秒 WAL 产出偏离基线 3 倍排查写入异常主库连接探测端口与健康检查成功率连续 3 次失败即告警WAL 磁盘剩余空间归档与预写日志容量剩余低于 20% 告警缓冲命中 / 内存buffer cache 命中率低于 90% 需排查演练节奏月度计划内窗口做一次主从切换演练验证应用自动重连链路季度kill 主库模拟真实故障验证自动故障切换的耗时与正确性年度全流程灾难恢复演练含原主回归与数据校验收个尾故障转移工具只是高可用的一半另一半是监控数据与演练记录。先选一个与团队运维水平匹配的工具在测试环境跑通第一次切换。让切换成为可验证的流程下一次真实故障才会只是告警日志里的一行记录。⚠️ 生产变更提醒任何故障转移方案先在测试环境验证并在业务低峰期执行动手前备好回滚预案VIP 回切、连接串回退、原主恢复步骤。【免费下载链接】awesome-postgresA curated list of awesome PostgreSQL software, libraries, tools and resources, inspired by awesome-mysql项目地址: https://gitcode.com/gh_mirrors/aw/awesome-postgres创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考