在 Ubuntu 上落地 PostgreSQL 高可用，常用且稳定的路径有：基于复制栈的Patroni+etcd（可叠加 VIP 或 HAProxy）、pg_repmgr、以及“主从+Keepalived VIP”的轻量方案。下面给出可操作的架构对比与关键配置步骤，便于快速选型与实施。
一、方案对比与适用场景
| 方案 |
组件与拓扑 |
自动故障转移 |
对外访问方式 |
优点 |
注意点 |
| Patroni + etcd + VIP |
3 节点 etcd + 2/3+ PostgreSQL 节点 + vip-manager |
是 |
虚拟 IP（VIP）或负载均衡 |
成熟、可编排、支持手动/自动切换 |
需维护一致性集群（etcd） |
| Patroni + etcd + HAProxy |
同上 + HAProxy 前置 |
是 |
HAProxy 读写分离/主路由 |
无状态代理、便于与现有 LB 体系融合 |
需健康检查与联动（如 callback） |
| pg_repmgr |
PostgreSQL + repmgrd 守护 |
是（配 repmgrd） |
VIP 或应用直连 |
轻量、与 PG 紧耦合、运维简单 |
需 SSH 免密、WAL 保留策略 |
| 主从 + Keepalived VIP |
主从复制 + Keepalived |
是（Keepalived） |
VIP |
实现简单、依赖少 |
脑裂风险、需严格网络与时间同步 |
上述组合在实际生产中被广泛采用：Patroni+etcd 负责控制面与自动故障转移，VIP 或 HAProxy 提供稳定接入；pg_repmgr 以复制管理为核心，配合守护进程实现自动切换；Keepalived VIP 方案实现成本低、易上手。
二、Patroni + etcd + VIP 快速落地
- 准备与安装
- 建议准备3 台 etcd（奇数台，便于选举）与2/3+ PostgreSQL 节点（Ubuntu 20.04/22.04/24.04 均可）。安装组件：PostgreSQL、etcd、Patroni（Ubuntu 可用系统仓库或 pip 安装），以及用于漂移 VIP 的vip-manager。
- 配置 Patroni（每个节点 /etc/patroni.yml 要点）
- 集群命名与作用域：scope、namespace
- DCS（etcd）连接与租约：如 ttl、loop_wait、retry_timeout
- PostgreSQL 参数：wal_level=replica、max_wal_senders、max_replication_slots、hot_standby=on、use_pg_rewind=true
- REST API：用于健康检查与切换（如 listen: 0.0.0.0:8008）
- 示例片段（关键项）：
- bootstrap.dcs.ttl: 30、loop_wait: 10、maximum_lag_on_failover
- bootstrap.postgresql.parameters: wal_level/replica、max_wal_senders/4、use_slots/true、use_pg_rewind/true
- postgresql.listen: 0.0.0.0:5432；data_dir: /var/lib/postgresql//main
- 启动与验证
- systemctl 启动 etcd、patroni；patronictl list/cluster show 查看角色与一致性
- 配置 vip-manager（指向 etcd/Consul 状态），为主库所在节点绑定VIP，对外提供稳定地址
- 接入与切换
- 应用/中间件连接 VIP 或 Patroni REST/HAProxy 前端；演练手动 switchover/failover，验证数据一致性与服务连续性
三、pg_repmgr 实操要点
- 安装与初始化
- 所有节点安装 PostgreSQL 与 repmgr；主库创建 repmgr 用户与库：CREATE USER repmgr SUPERUSER REPLICATION PASSWORD ‘…’; CREATE DATABASE repmgr OWNER repmgr;
- 主库关键配置（postgresql.conf）
- wal_level=replica、wal_log_hints=on、max_wal_senders≥10、hot_standby=on、archive_mode=on、archive_command（如 ‘test ! -f /arch/%f && cp %p /arch/%f’）
- pg_hba.conf 放行复制与 repmgr：host replication all <网段>/<掩码> md5；host repmgr all <网段>/<掩码> trust/md5
- 从库搭建
- 使用 repmgr 克隆：repmgr -f /etc/repmgr//repmgr.conf standby clone
- 启动从库后执行：repmgr -f … standby follow
- 自动故障转移
- 启动守护进程：repmgrd -f …；配置故障策略与告警；定期 repmgr cluster show 巡检
- 扩展与仲裁
- 可加入 Witness 节点提升仲裁可靠性（如 3 数据节点 + 1 witness）
四、主从 + Keepalived VIP 轻量方案
- 适用场景
- 资源受限或希望最小化外部依赖时，可采用主从复制 + Keepalived 实现 VIP 漂移，对外保持单一连接地址。
- 实施要点
- 主从完成流复制（wal_level=replica、max_wal_senders、hot_standby=on 等）；应用连接 VIP:5432
- Keepalived 配置 VRRP 实例与健康检查脚本（如基于 psql 的 replication lag 或角色判断）；主库异常时降低优先级，备库接管 VIP
- 建议配合 WAL 归档与监控告警，降低脑裂与数据丢失风险
五、通用加固与运维要点
- 复制与健康
- 合理设置 WAL 保留（如 wal_keep_segments 或使用复制槽）、监控复制延迟（如 pg_stat_replication）；启用日志与告警
- 安全与网络
- 复制与管理通道使用强认证（scram-sha-256）、最小权限；跨机房/公网部署启用 TLS；保证 NTP/chrony 时间同步
- 变更与演练
- 任何参数变更先在测试环境验证；定期执行故障转移演练与备份恢复演练；保留回滚预案
- 连接入口治理
- 统一通过 VIP/HAProxy/Patroni REST 接入，避免应用直连具体节点；读写分离在代理层或应用侧明确策略
以上方案均可满足不同规模与复杂度的可用性需求：追求自动化与可编排性优先选择Patroni+etcd；希望轻量运维可选pg_repmgr；极致简化可用Keepalived VIP。无论采用哪种路径，务必结合业务 RPO/RTO、团队运维能力与网络条件进行选型与验证。
