PostgreSQL 高可用与故障转移详解3 种主流方案选型 1 套落地清单【免费下载链接】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 的 High-Availability 清单入手。⚖️ 选型决策按部署场景匹配方案与其罗列工具功能不如先问节点怎么摆。不同场景对共识组件的要求完全不同这一步定错了后面全是返工。部署场景推荐方案选型理由单机房 23 节点repmgr无额外依赖安装轻、上手快小团队维护成本最低跨可用区、3 节点及以上Patronietcd / Consul 做共识存储分布式锁防脑裂切换决策自动考虑副本优先级与延迟Kubernetes 环境Patroni Operator或 Stolon与 Service、PVC 深度集成节点漂移由平台层接管三方案关键差异速览方案外部依赖切换方式维护成本repmgr无可选监控守护进程repmgr standby promote手动或事件触发自动低Patronietcd / Consul / ZooKeeper 三节点全自动秒级决策中共识集群需独立维护pg_auto_failover无监控扩展 守护服务自动提升中扩展与服务两层pg_auto_failover 适合已有流复制、跑在云 VM 上、不想再引入任何组件的存量集群是三选一里门槛最低的。⚙️ 从手动到自动切换能力的升级路径建议把切换能力拆成两级建设先做到人能切再谈系统能切。跳过手动直接上自动出问题时你会连切到底发生了什么都不知道。手动 promote 的四个检查点以 repmgr 为例裸pg_promote()流程同理确认主库确实救不回来先排除网络隔离、主机假死能 SSH 进主节点并看到实例在起就别动核对备库进度在备库查SELECT pg_last_wal_replay_lsn()与主库最后已知位置对比差距大就先追 WAL 再切执行提升repmgr standby promote -h standby1观察输出确认角色已变更收敛流量并重组VIP 或 DNS 指向新主原主修复后重新初始化为备避免它以旧身份回来直接双写。手动切换的核心判断只有一条延迟是否可接受。业务允许 RPO 非零就用异步复制求快要求零丢失就配同步复制没有中间态。Patroni 接入 etcd 的最小配置跨可用区或节点数上来后引入 Patroni etcd。核心其实就三个关注点DCS 地址、切换时间窗、延迟容忍度。scope: pg-ha-cluster # 集群名所有节点必须一致 etcd3: hosts: 192.168.1.21:2379,192.168.1.22:2379,192.168.1.23:2379 ttl: 10 # leader 租约时长秒 loop_wait: 5 # 健康检查间隔秒 maximum_lag_on_failover: 30 # 延迟超该阈值MB的节点不得参选PostgreSQL 高可用故障转移Patroni 自动切换流程示意图切换决策靠 etcd 的 leader 锁保证任一时刻只有一个主脑裂问题在机制层被消掉。maximum_lag_on_failover是数据安全的闸门——宁可多等一个更同步的副本也不提升一个落后太多的备库。 生产落地检查清单部署前复制模式书面确定同步还是异步synchronous_standby_names写死不许默认值共识组件如有按奇数节点跨机房部署并单独纳入监控应用连接串一律走 VIP / DNS / 服务名禁止直连物理节点 IP。切换中4. DCS 中确认唯一 leader新主上查pg_stat_replication状态 5. 确认旧主已回退为 recovery 状态而不是被直接拉起。切换后6. 跑一次读写冒烟测试确认监控面板已指向新主 7. 记录切换时间线与误判事件归档进故障单。PostgreSQL 主备切换检查清单与故障排查流程示意图故障场景速查表场景现象根因处置动作预防措施脑裂双主两侧pg_stat_replication均为空应用报冲突无共识锁或 DCS 失联导致双提升立即停写数据较少一侧重新降级上 Patroni leader 锁DCS 可用性按不低于数据库对待切完应用仍超时新主正常业务连接仍报错连接池持有失效连接VIP 未收敛PgBouncer 回收连接或重启池核对 DNS TTLTTL 压到 3060 秒应用端配置自动重连切换后数据缺失新主缺最后一批事务异步复制延迟未追上就提升依据 WAL 归档评估补数核心业务改同步复制设置延迟阈值限制参选备库延迟持续上涨pg_stat_wal_receiver滞后不回落主库 WAL 生成速率超过备库回放 IO错峰写入或升级备库磁盘对回放延迟设分级告警备库存储与主库同级监控与定期验证指标盯四个副本回放延迟按秒级窗口告警而不是有延迟才报、WAL 生成速率、连接数水位、主节点磁盘与 IOPS。告警要带明确阈值和值班人否则形同虚设。演练节奏每月维护窗口做一次计划内切换每季度模拟一次拔网线 / 停实例式主节点失联每年做一次含数据校验的完整灾备。每次演练都要留工单结论要能查到。回到开头那个凌晨三点的场景——决定你能不能从容的不是工具多新而是切换检查点是否已经演练过、监控是否先于人声发出警报。这周就能做的第一步挑一个非生产集群把上面手动 promote 的四个检查点打印出来对着做一次走查哪里卡壳了哪里就是下一个要修的点。【免费下载链接】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 6:26:35 · 阅读 1.2k PostgreSQL 高可用与故障转移详解：3 种主流方案选型 + 1 套落地清单
PostgreSQL 高可用与故障转移详解3 种主流方案选型 1 套落地清单【免费下载链接】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 的 High-Availability 清单入手。⚖️ 选型决策按部署场景匹配方案与其罗列工具功能不如先问节点怎么摆。不同场景对共识组件的要求完全不同这一步定错了后面全是返工。部署场景推荐方案选型理由单机房 23 节点repmgr无额外依赖安装轻、上手快小团队维护成本最低跨可用区、3 节点及以上Patronietcd / Consul 做共识存储分布式锁防脑裂切换决策自动考虑副本优先级与延迟Kubernetes 环境Patroni Operator或 Stolon与 Service、PVC 深度集成节点漂移由平台层接管三方案关键差异速览方案外部依赖切换方式维护成本repmgr无可选监控守护进程repmgr standby promote手动或事件触发自动低Patronietcd / Consul / ZooKeeper 三节点全自动秒级决策中共识集群需独立维护pg_auto_failover无监控扩展 守护服务自动提升中扩展与服务两层pg_auto_failover 适合已有流复制、跑在云 VM 上、不想再引入任何组件的存量集群是三选一里门槛最低的。⚙️ 从手动到自动切换能力的升级路径建议把切换能力拆成两级建设先做到人能切再谈系统能切。跳过手动直接上自动出问题时你会连切到底发生了什么都不知道。手动 promote 的四个检查点以 repmgr 为例裸pg_promote()流程同理确认主库确实救不回来先排除网络隔离、主机假死能 SSH 进主节点并看到实例在起就别动核对备库进度在备库查SELECT pg_last_wal_replay_lsn()与主库最后已知位置对比差距大就先追 WAL 再切执行提升repmgr standby promote -h standby1观察输出确认角色已变更收敛流量并重组VIP 或 DNS 指向新主原主修复后重新初始化为备避免它以旧身份回来直接双写。手动切换的核心判断只有一条延迟是否可接受。业务允许 RPO 非零就用异步复制求快要求零丢失就配同步复制没有中间态。Patroni 接入 etcd 的最小配置跨可用区或节点数上来后引入 Patroni etcd。核心其实就三个关注点DCS 地址、切换时间窗、延迟容忍度。scope: pg-ha-cluster # 集群名所有节点必须一致 etcd3: hosts: 192.168.1.21:2379,192.168.1.22:2379,192.168.1.23:2379 ttl: 10 # leader 租约时长秒 loop_wait: 5 # 健康检查间隔秒 maximum_lag_on_failover: 30 # 延迟超该阈值MB的节点不得参选PostgreSQL 高可用故障转移Patroni 自动切换流程示意图切换决策靠 etcd 的 leader 锁保证任一时刻只有一个主脑裂问题在机制层被消掉。maximum_lag_on_failover是数据安全的闸门——宁可多等一个更同步的副本也不提升一个落后太多的备库。 生产落地检查清单部署前复制模式书面确定同步还是异步synchronous_standby_names写死不许默认值共识组件如有按奇数节点跨机房部署并单独纳入监控应用连接串一律走 VIP / DNS / 服务名禁止直连物理节点 IP。切换中4. DCS 中确认唯一 leader新主上查pg_stat_replication状态 5. 确认旧主已回退为 recovery 状态而不是被直接拉起。切换后6. 跑一次读写冒烟测试确认监控面板已指向新主 7. 记录切换时间线与误判事件归档进故障单。PostgreSQL 主备切换检查清单与故障排查流程示意图故障场景速查表场景现象根因处置动作预防措施脑裂双主两侧pg_stat_replication均为空应用报冲突无共识锁或 DCS 失联导致双提升立即停写数据较少一侧重新降级上 Patroni leader 锁DCS 可用性按不低于数据库对待切完应用仍超时新主正常业务连接仍报错连接池持有失效连接VIP 未收敛PgBouncer 回收连接或重启池核对 DNS TTLTTL 压到 3060 秒应用端配置自动重连切换后数据缺失新主缺最后一批事务异步复制延迟未追上就提升依据 WAL 归档评估补数核心业务改同步复制设置延迟阈值限制参选备库延迟持续上涨pg_stat_wal_receiver滞后不回落主库 WAL 生成速率超过备库回放 IO错峰写入或升级备库磁盘对回放延迟设分级告警备库存储与主库同级监控与定期验证指标盯四个副本回放延迟按秒级窗口告警而不是有延迟才报、WAL 生成速率、连接数水位、主节点磁盘与 IOPS。告警要带明确阈值和值班人否则形同虚设。演练节奏每月维护窗口做一次计划内切换每季度模拟一次拔网线 / 停实例式主节点失联每年做一次含数据校验的完整灾备。每次演练都要留工单结论要能查到。回到开头那个凌晨三点的场景——决定你能不能从容的不是工具多新而是切换检查点是否已经演练过、监控是否先于人声发出警报。这周就能做的第一步挑一个非生产集群把上面手动 promote 的四个检查点打印出来对着做一次走查哪里卡壳了哪里就是下一个要修的点。【免费下载链接】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），仅供参考