PostgreSQL高可用通过流复制与故障转移工具实现，核心为数据复制、故障检测与自动切换。主流方案包括Patroni+etcd、repmgr和Pgpool-II，其中Patroni因自动化强、防脑裂优被广泛推荐。搭建时需准备多节点环境，部署etcd集群，配置Patroni参数，启动后验证主备切换与数据一致性。关键点包括同步模式选择、脑裂防护、备份策略、监控告警及客户端重连机制，确保系统稳定可靠。
搭建 PostgreSQL 高可用（HA）集群，核心目标是保证数据库在出现硬件故障、网络中断或主节点宕机时仍能持续提供服务。实现这一目标的关键在于数据复制、故障检测与自动切换。目前主流的 PostgreSQL HA 架构依赖于流复制 + 故障转移工具组合，下面从架构原理到具体搭建逻辑进行深入说明。
PostgreSQL 高可用基本架构组成
一个典型的 PostgreSQL HA 集群通常包含以下组件：
- 主节点（Primary）：处理所有读写请求，生成 WAL 日志并发送给备节点。
- 备节点（Standby/Replica）：通过流复制接收主节点的 WAL 日志，实时应用以保持数据一致。可配置为同步或异步模式。
- 流复制（Streaming Replication）：PostgreSQL 内建机制，允许备库从主库实时获取 WAL 记录，延迟低。
- 故障检测与自动切换工具：如 Patroni、repmgr、Pgpool-II 等，用于监控节点状态并在主节点失效时提升备节点为主节点。
- 一致性协调服务（可选）：如 etcd、Consul 或 ZooKeeper，用于存储集群状态、选举领导者，常与 Patroni 配合使用。
常见高可用方案对比
不同工具组合形成不同的高可用架构，各有适用场景：
1. Patroni + etcd + Streaming Replication
这是当前最推荐的生产级方案。Patroni 是用 Python 编写的 PostgreSQL 高可用管理框架，它通过 etcd 维护集群成员和 leader 信息，自动完成主备切换。
- 支持同步/异步复制模式。
- 基于 DCS（Distributed Configuration Store）实现脑裂防护。
- 提供 REST API 查询集群状态。
- 适合大规模、自动化运维环境。
2. repmgr（Replication Manager）
由 EnterpriseDB 开发，专为 PostgreSQL 流复制设计的开源工具。
- 管理主备切换、监控、克隆和重建备库。
- 依赖 witness server 防止脑裂。
- 配置相对简单，适合中小规模部署。
- 不依赖外部 DCS，自身维护元数据表。
3. Pgpool-II + Streaming Replication
Pgpool 不仅支持负载均衡和连接池，也可实现高可用。
- 内置健康检查和自动故障转移功能。
- 可配合 watchdog 实现 Pgpool 自身的高可用。
- 适合需要读写分离和连接池优化的场景。
- 复杂查询可能因解析问题导致错误，需谨慎使用 SQL 模式。
以 Patroni 为例的搭建要点
以下是使用 Patroni + etcd + PostgreSQL 搭建三节点 HA 集群的核心步骤：
1. 环境准备
- 至少三台服务器（建议 3 个 PostgreSQL 节点 + 3 个 etcd 节点，可复用）。
- 安装 PostgreSQL（版本一致），关闭防火墙或开放对应端口（5432、2379、8008 等）。
- 安装 Python3 和 pip，用于运行 Patroni。
2. 部署 etcd 集群
- 配置三个 etcd 节点组成集群，确保其自身高可用。
- 设置正确的 peer 和 client URL，启用安全认证更佳。
- 测试 etcd 集群状态：
etcdctl endpoint health
3. 安装并配置 Patroni
- 使用 pip 安装 Patroni：
pip install patroni[etcd] - 每个节点编写 YAML 配置文件，定义 PostgreSQL 参数、etcd 地址、复制用户、角色等。
- 示例片段：
scope: postgres-ha name: pg-node-1 <p>restapi: listen: 0.0.0.0:8008 connect_address: 192.168.1.10:8008</p><p>etcd: hosts: [192.168.1.10:2379, 192.168.1.11:2379, 192.168.1.12:2379]</p><p>bootstrap: dcs: replication: username: repl password: replpass primary_start_timeout: 300 initdb:</p><ul><li>encoding: UTF8</li><li>data-checksums</li></ul><p>postgresql: listen: 0.0.0.0:5432 connect_address: 192.168.1.10:5432 data_dir: /var/lib/postgresql/14/main bin_dir: /usr/lib/postgresql/14/bin authentication: replication: username: repl password: replpass superuser: username: postgres password: postgrespass</p>
4. 启动集群
- 先启动 etcd 集群。
- 按顺序启动 Patroni 服务（systemd 或直接运行）。
- 第一个节点会自动初始化为 Primary，其余节点作为 Replica 加入。
- 通过
patronictl list查看集群状态。
5. 验证高可用性
- 手动停止主节点的 Patroni 服务，观察是否有新主被选举。
- 原主恢复后应自动作为备库重新加入。
- 检查数据一致性，确认无丢失（特别是在异步模式下注意潜在风险）。
关键注意事项
搭建过程中有几个容易忽略但至关重要的点：
- 同步模式选择：同步复制（SYNC）可保证零数据丢失，但性能下降明显；异步复制性能好，但有数据丢失风险。可通过“半同步”（quorum commit）平衡两者。
- 脑裂防护：必须依赖外部仲裁机制（如 etcd 多数派投票）防止多个节点同时认为自己是主库。
- 备份策略整合：HA 不等于备份。仍需定期使用 pg_basebackup 或 Barman 做物理备份，并测试恢复流程。
- 监控与告警：集成 Prometheus + Grafana 监控复制延迟、节点状态、WAL 发送情况。
- 客户端重连机制：应用层需具备重连能力，或使用 HAProxy + Keepalived 提供虚拟 IP 接入。
基本上就这些。PostgreSQL 高可用的本质是“复制 + 控制 + 切换”的闭环，选择合适的工具链并合理配置，才能在稳定性和性能之间取得平衡。
