数据库与存储 · 高级

PostgreSQL 高可用

用 Patroni、etcd 与 HAProxy 建立 PostgreSQL 单主访问链路,明确复制一致性、旧主隔离和恢复验收。

LinuxPostgreSQL自动化高可用

场景目标

在测试环境形成一次受控切换记录:写入口始终最多一个主节点,旧主隔离可验证,复制与事务核对满足选定 RPO,连接恢复耗时满足约定 RTO;生产接入前完成恢复演练并保留证据。

环境要求

参考 PostgreSQL 17、Patroni 4.x、etcd 3.6 与 HAProxy 受支持版本,实际组合须核对兼容性。至少三个数据库节点、三个跨故障域 etcd 成员及冗余代理入口;数据节点预留完整数据副本、WAL 峰值和重建空间。需数据库管理员、主机服务配置和受控网络权限,凭据由保密文件或凭据系统提供。安排不少于 240 分钟的测试窗口;数据复制、备份恢复和完整业务观察可能另需数小时至数天,不计入估算。实施前须有独立恢复环境、可用备份、fencing 通道和中止负责人。

参考架构 · 非实时拓扑

WAL 复制、DCS 租约与写入口隔离架构

PostgreSQL 主副本传递 WAL,节点本地 Patroni 经 etcd 协调角色,HAProxy 查询主角色接口路由新连接;可靠旧主隔离与独立备份分别保护写入和恢复。

  • 数据 / 请求
  • 控制 / 管理
  • 观测 / 查询

点击组件,在图下方查看职责;连线编号对应流向解读。小屏可横向滚动,或直接展开文字说明。

WAL 复制、DCS 租约与写入口隔离架构:组件关系图PostgreSQL 主副本传递 WAL,节点本地 Patroni 经 etcd 协调角色,HAProxy 查询主角色接口路由新连接;可靠旧主隔离与独立备份分别保护写入和恢复。 应用连接池 → HAProxy:业务连接;HAProxy → PostgreSQL 主库:转发当前主连接;PostgreSQL 主库 → PostgreSQL 副本:WAL 流复制;节点本地 Patroni → etcd DCS 组:租约与协调读写;节点本地 Patroni → PostgreSQL 主库:受约束管理角色;HAProxy → 节点本地 Patroni:探测 /primary;节点本地 Patroni → watchdog / 隔离:隔离安全前提;watchdog / 隔离 → PostgreSQL 主库:阻止失权旧主写入;PostgreSQL 副本 → 独立备份与恢复:经核验的备份路径。箭头说明见下方流向解读。
逻辑参考图,Patroni 表示每台数据节点上的进程,etcd 与副本按逻辑组聚合;不代表真实自动切换、隔离或备份恢复已经验收。

应用连接池

入口 / 来源

使用已有冗余代理入口,处理旧长连接和提交结果未知的事务;不能无条件重放所有写请求。

全部组件职责 8 个组件
应用连接池
使用已有冗余代理入口,处理旧长连接和提交结果未知的事务;不能无条件重放所有写请求。
HAProxy
依据 Patroni 主角色健康端点选择写后端,代理自身需已有冗余入口;数据库端口存活不足以证明可写角色。工具介绍 HAProxy
etcd DCS 组
保存协调状态与领导租约,成员通信和磁盘健康影响多数可用性;etcd 多数不是 PostgreSQL 数据复制多数。工具介绍 etcd DCS 组
节点本地 Patroni
每台数据节点分别运行 Patroni,本节点按 DCS 租约及复制约束管理 PostgreSQL。图中聚合展示,不是中央单实例控制器。工具介绍 节点本地 Patroni
PostgreSQL 主库
承接写事务并输出 WAL。复制模式与事务参数决定实际一致性边界,不能因 DCS 健康就承诺零丢失。工具介绍 PostgreSQL 主库
watchdog / 隔离
采用经过目标环境验证的 watchdog 或外部 fencing,明确租约丢失、进程卡死和网络隔离时的阻写责任与恢复通道。
独立备份与恢复
保存独立恢复所需基础备份与 WAL,并在隔离环境核对。图示从合格副本取备份为可选路径,需要验证其配置和完整性。
PostgreSQL 副本
持续接收与回放 WAL,候选资格需核对滞后、时间线和同步配置;本场景主库与两副本分别运行 Patroni。工具介绍 PostgreSQL 副本
流向解读 9 条连接
  1. 1

    应用连接池 HAProxy

    数据 / 请求 · 业务连接

    应用经已有冗余入口发送请求,角色变化时需重建失效连接并核对不确定事务。

  2. 2

    HAProxy PostgreSQL 主库

    数据 / 请求 · 转发当前主连接

    写后端仅选择经角色检查确认的主节点,不能把健康端口中的所有数据库都当作可写后端。

  3. 3

    PostgreSQL 主库 PostgreSQL 副本

    数据 / 请求 · WAL 流复制

    WAL 从主库传到副本;同步模式和提交设置需分别评审,图示复制方向不表示所有事务已经同步确认。

  4. 4

    节点本地 Patroni etcd DCS 组

    控制 / 管理 · 租约与协调读写

    各节点 Patroni 访问 DCS 维护角色协调信息,DCS 多数丢失的降级策略必须先定义。

  5. 5

    节点本地 Patroni PostgreSQL 主库

    控制 / 管理 · 受约束管理角色

    节点本地 Patroni 按有效租约、复制资格及隔离要求管理角色;图中同类本地控制也存在于副本节点。

  6. 6

    HAProxy 节点本地 Patroni

    观测 / 查询 · 探测 /primary

    代理请求各节点 Patroni 的 /primary 等主角色健康端点,要求数据库为主且持有领导锁,不用 /health 代替角色判断。

  7. 7

    节点本地 Patroni watchdog / 隔离

    控制 / 管理 · 隔离安全前提

    表示配置并验证 watchdog 或外部隔离职责;外部 fencing 的执行方取决于实际方案,不默认 Patroni 内置所有隔离能力。

  8. 8

    watchdog / 隔离 PostgreSQL 主库

    控制 / 管理 · 阻止失权旧主写入

    失去领导资格时,旧节点必须无法继续通过直连或旧连接接写,代理摘除不能独自提供该保证。

  9. 9

    PostgreSQL 副本 独立备份与恢复

    数据 / 请求 · 经核验的备份路径

    可从满足备份条件的副本取基础备份,并确保所需 WAL 完整;也可按原方案选择主库,必须独立恢复校验。

从架构到实施

  1. 01

    把协调多数与复制模式分别确认

    先定义业务恢复目标并核对备份证据,再检查 etcd 三成员故障域,选择异步或受管理同步模式并建立副本。

  2. 02

    先证明隔离,再开放角色路由

    验证 watchdog 或外部 fencing 失效时的停止条件,HAProxy 用主角色接口判定后端,并测试应用连接重建。

  3. 03

    从故障时间线验证独立恢复

    逐项测试计划切换、DCS 和网络故障,核对事务与时间线;旧主按副本恢复,再完成隔离备份还原和运行交接。

故障域与操作边界

DCS 多数与数据提交不是一回事

etcd 多数用于角色协调;默认异步复制仍可能丢失已确认事务,同步 strict 模式也可能因缺少同步副本阻塞写入。

代理摘除不能代替可靠隔离

旧长连接或直连可能绕过代理。失权旧主的阻写、watchdog 可用性与外部 fencing 必须在提升前按实际方案验证。

时间线分叉不能直接自动回切

旧主重新加入前保留 WAL 与事务证据,按可信主库重同步;高可用副本不能代替独立备份或跨地域恢复验证。

架构依据与版本核对 5 篇官方资料

图解是本站基于官方资料整理的逻辑参考;实施前仍需核对实际部署版本、组件支持范围与变更审批。

方案说明

架构与适用范围

三台 PostgreSQL 数据节点分别运行 Patroni,由跨故障域的三成员 etcd 保存协调状态;HAProxy 依据 Patroni 的主节点健康接口选择写后端。应用需支持连接重建,并对提交结果不确定的事务进行业务核对。代理自身需采用已有的冗余入口。

不适用边界

本文是待目标环境验证的实施流程,不表示已部署或完成故障演练。它不覆盖跨地域自动容灾、跨大版本升级或双主写入。etcd 多数用于协调,不等于数据复制多数;默认异步复制可能丢失已确认事务。同步模式增加写入约束,strict 模式在缺少同步副本时可能阻塞写入,仍需理解事务设置和故障组合的边界。

全局验收

各时刻仅一个节点能经写入口接收写入;旧主在新主提升前被可靠隔离,DCS 多数丢失时符合既定降级策略。记录切换时间、恢复后事务核对结果及复制延迟,将实测结果与预先签定的 RPO/RTO 对照。备份必须能恢复到独立环境,高可用不能替代备份。

官方参考

工具编排

4 个关联工具
  1. PostgreSQL数据与复制保存业务数据,提供 WAL、流复制、事务状态与独立恢复能力。
  2. Patroni主节点编排通过 DCS 租约协调节点角色,并执行符合复制约束的切换。
  3. etcd分布式协调保存租约和集群状态,其多数与数据库复制状态分别验收。
  4. HAProxy数据库入口依据 Patroni 主角色健康检查路由新连接,配合应用连接重建。

实施步骤

共 7 步
  1. 01

    确认恢复目标与数据库基线

    与业务负责人确定可接受的数据丢失量、写中断时间、事务重试方式及停止条件,登记节点、故障域和当前备份位置。使用现有只读连接配置查看版本及角色,连接配置不得在终端输出口令。核对最近一次恢复记录,尚未做过恢复验证时先安排独立恢复,不把备份任务成功视为可恢复的证据。

    SHOW server_version;
    SELECT pg_is_in_recovery();
    验证标准

    清单包含全部节点、业务入口、复制模式候选和明确的恢复目标;版本与角色查询可追溯,恢复记录能说明备份时间点、完整性及实际恢复耗时,由数据库和业务负责人共同确认。

    停止与回退

    本步骤只读取状态,不改变数据库。若恢复证据、权限或业务目标不完整,暂停接入新组件并补齐清单;保留原连接入口和当前备份策略,避免在前置条件不足时进入切换流程。

    返回步骤起点
  2. 02

    核验 DCS 多数与故障域

    规划三个独立成员的 etcd 集群,核对成员不集中在同一宿主机或电源故障域,并为成员间通信启用证书与来源限制。通过已配置 TLS 的管理环境读取端点状态,记录成员 ID、任期和磁盘延迟基线。确认网络分区时哪一侧可形成多数,避免将两个成员误当成可容忍单节点故障的设计。

    etcdctl endpoint status --cluster --write-out=table
    etcdctl member list --write-out=table
    验证标准

    三个成员身份唯一且状态一致,证书有效期与防火墙范围可核对;单个故障域失效后仍具备所需多数。快照保存位置、恢复负责人和 DCS 不可用时的应用表现已有书面记录。

    停止与回退

    本步骤的状态查询无写入;如端点或故障域不符合设计,停止数据库初始化。撤回本次尚未启用的客户端配置,保持现有协调集群不变,不通过强制重建成员关系掩盖多数问题。

    返回步骤起点
  3. 03

    选择复制模式并建立数据副本

    根据业务取舍选择异步或 Patroni 管理的同步模式,记录最大允许复制滞后、同步副本数量及写入可用性要求。异步切换的数据丢失窗口还受 WAL 采样与租约周期影响,不能仅用一个滞后参数承诺零丢失。从已验证备份建立副本,检查扩展、校验和或 WAL 配置满足后续恢复需要,并预留复制槽滞留时的磁盘告警。

    验证标准

    各节点版本和扩展相容,副本持续追上 WAL,复制槽及归档没有持续积压。配置审阅能明确说明同步副本缺失时是否阻塞写入,以及应用事务设置是否可能绕开预期的一致性保证。

    停止与回退

    若新副本初始化失败,停止该副本的受控初始化流程并保留错误记录,不修改现有主库数据。恢复此前的复制参数前先核对对业务一致性的影响,新产生的数据目录按保留策略处理。

    返回步骤起点
  4. 04

    验证旧主隔离和提升约束

    为 Patroni 配置经过环境验证的 watchdog 或外部 fencing 机制,说明失去租约、进程卡死和网络隔离分别由谁阻止旧主继续写入。需要 watchdog 的节点应在装置不可用时拒绝提升,确认重启风险和恢复通道。将隔离检查纳入提升条件,在测试节点验证完成后才开放自动切换,禁止把代理摘除当作唯一的防双主手段。

    验证标准

    有证据表明失去领导资格的节点不能继续通过直连或旧连接写入,新主提升条件与隔离完成顺序一致。测试结果覆盖配置要求失效的情况,fencing 操作和恢复路径均可追溯至具体节点。

    停止与回退

    隔离机制未通过时关闭本次新增的自动切换路径,维持已知单主状态并安排人工处理。不要为恢复写入而跳过隔离强制提升;如果发生疑似双主,先冻结受影响入口并保存两侧事务证据。

    返回步骤起点
  5. 05

    配置主角色探测与业务连接

    让 HAProxy 使用 Patroni 主角色健康端点判断写后端,管理 API 只开放给指定代理和管理员。建立单独的只读入口时同时考虑复制滞后,不以端口存活替代角色判断。先从测试客户端验证连接重建、连接池刷新和事务结果核对,再分批接入业务;对旧长连接的退出方式及代理自身冗余入口安排明确的验收。

    验证标准

    写后端列表始终只有当前主节点,副本不会因端口可达而接收写流量;角色变化后新连接能转向新主。测试客户端记录重连耗时与不确定事务,代理故障时冗余入口也能按既定方式接管。

    停止与回退

    出现误路由或持续重连失败时,将测试客户端恢复到预先保留的稳定入口,撤回本次代理配置。确认实际主角色后再恢复业务,避免同时保留两个可写入口或直接重放结果不明的事务。

    返回步骤起点
  6. 06

    在测试窗口演练切换与恢复

    先进行健康节点间的计划切换,再按批准的故障矩阵逐项测试主进程失效、单个 DCS 成员失效和网络隔离。每次仅引入一种故障,记录隔离、选主、代理切换及客户端恢复的时间线。用独立测试业务流水核对确认提交、失败和结果不明的事务;旧主回归前核对时间线分叉,并按既定重同步方案处理。

    验证标准

    每项故障均有起止时间、主角色变化和业务核对结果,实测 RPO/RTO 满足预先定义的目标;没有双主写入。旧主以副本角色重新加入并追平,未通过的故障项明确标注且阻止生产接入。

    停止与回退

    任何双主迹象或丢失超出目标时立即停止故障注入,隔离争议节点并保留 WAL 与业务流水。由负责人选择可信主库后恢复入口,不自动回切,也不在事务证据未保存前重建旧主数据。

    返回步骤起点
  7. 07

    完成备份恢复与运行交接

    在隔离恢复环境执行一次备份恢复和指定时间点的数据核对,确认恢复过程不依赖发生故障的原主节点。将复制滞后、WAL 空间、DCS 状态、证书到期及代理后端异常纳入值班看板,明确告警负责人。整理配置版本、演练缺口与人工接管流程,按约定观察窗口完成验收;所有尚未执行的项目保持待验证状态。

    验证标准

    独立恢复后的数据抽样及业务核对合格,监控信号能送达值班人员。交接材料包含实际恢复耗时、可接受的数据边界、故障处理入口和剩余风险,业务观察完成后由责任人签署验收。

    停止与回退

    恢复或观察未通过时暂缓扩大接入,保留当前已确认稳定的服务形态和原备份链路。撤回新增但误报的告警规则须保留替代监测方式,记录整改项后重新安排验证,不能以文档交接代替验收。

    返回步骤起点

DOUYA OPS ECOSYSTEM

体验豆芽自研工具与场景能力

部分场景提供体验环境,用于功能验证、测试和技术交流。