PostgreSQL在Ubuntu上的高可用性如何实现

在 Ubuntu 上实现 PostgreSQL 高可用

一、方案总览与选型

• 常见路径包括：基于流复制的主从复制（手动或脚本切换）、借助管理工具实现自动故障转移（如 Patroni、pg_repmgr）、以及用 Keepalived 或 Pacemaker+Corosync 提供 VIP 与资源编排。流复制负责数据同步，工具或集群栈负责选主、切换与服务发现，VIP 或连接路由负责对外提供稳定入口。对于读多写少场景，可在从节点开启只读查询实现读写分离，提升吞吐。

二、方案一 流复制 + Keepalived 手动切换（轻量、易落地）

• 适用：两节点为主备，要求快速搭建与可控切换。
• 核心思路：主库开启流复制，备库通过基础备份建立；用 Keepalived 在主库上绑定 VIP，主备检测脚本联动切换 VIP，应用通过 VIP 访问数据库。
• 关键配置要点
  • 主库 postgresql.conf（示例）：
    • listen_addresses = ‘*’
    • wal_level = replica
    • max_wal_senders ≥ 从库数量（如 3）
    • archive_mode = on
    • archive_command = ‘test ! -f /mnt/server/archivedir/%f && cp %p /mnt/server/archivedir/%f’
    • hot_standby = on（备库）
  • 主库创建复制用户与复制槽（示例）：
    • CREATE ROLE replica_user WITH REPLICATION LOGIN PASSWORD ‘YOUR_SECURE_PASSWORD’;
    • SELECT pg_create_physical_replication_slot(‘secondary_slot’);
  • 备库建立：先停止数据库，使用 pg_basebackup 从主库拉取数据，配置 recovery.conf/standby.signal 与 primary_conninfo，然后启动；按需开启 hot_standby 提供只读。
  • Keepalived：配置 VRRP 实例与 state/priority，实现主备抢占或优先级切换；健康检查脚本探测 PostgreSQL（如通过 psql 连接或监控 replication lag），失败时降低优先级或移除 VIP，由备库接管。
• 优点/局限：部署简单、依赖少；自动故障转移能力取决于 Keepalived 脚本质量，需规范切换流程与回切演练。

三、方案二 自动故障转移与编排（Patroni 或 pg_repmgr）

• 适用：需要自动选主、自动故障转移、配置管理与 API/脚本化集成的生产环境。
• Patroni
  • 组成：Patroni（管理 PostgreSQL 启停与复制）、DCS（如 etcd/Consul/ZooKeeper，负责锁与状态）、REST API（健康检查与切换入口）。
  • 关键配置（示例要点）：
    • scope 与 name 标识集群与节点；restapi 监听地址；etcd 连接；
    • bootstrap.dcs 中设置 ttl/loop_wait/retry_timeout、use_pg_rewind、use_slots、以及 postgresql.parameters（wal_level、max_wal_senders、hot_standby 等）；
    • postgresql.listen/connect_address、data_dir、pg_hba 与复制/超级用户认证。
  • 运行与切换：patroni /etc/patroni.yml 启动；通过 API 或集群工具查看状态、执行 switchover/failover。
• pg_repmgr
  • 组成：pg_repmgr（复制与集群管理）、repmgrd（守护进程，故障检测与自动切换）。
  • 关键步骤：
    • 各节点安装 PostgreSQL 与 repmgr；主库配置 wal_level/replication 等并创建 repmgr 用户/库；
    • 备库用 repmgr standby clone 建立复制；启动后执行 repmgr standby follow；
    • 启动 repmgrd 实现监控与自动故障转移；用 repmgr cluster show 查看拓扑与角色。
• 优点/局限：自动选主与快速切换、可观测性强、与云原生生态易集成；需维护 DCS 或守护进程，部署复杂度高于 Keepalived。

四、方案三 Pacemaker + Corosync 与 VIP 编排（传统 HA 栈）

• 适用：已有 Pacemaker 经验或需要与其它资源（如虚拟 IP、文件系统、Fence 设备）统一编排的场景。
• 架构要点：Corosync 提供消息层，Pacemaker 做资源代理（RA）；数据库与 VIP 作为集群资源受控启停；可配置主库 RW VIP 与从库 RO VIP 实现读写分离入口。
• 实施提示：
  • 安装 pacemaker/corosync/pcs；初始化集群与认证；
  • 禁止 PostgreSQL 开机自启，由 Pacemaker 管理；配置 PostgreSQL RA 与 VIP RA；
  • 设置 STONITH/fencing 策略保障脑裂安全；定义启动顺序与约束（如主库先起、VIP 绑定在主库）。
• 优点/局限：企业级 HA 能力强、可编排多类资源；部署与调优复杂度较高，对运维经验有要求。

五、落地检查清单与最佳实践

• 复制与健康
  • 主库：wal_level=replica、max_wal_senders 充足、开启 WAL 归档、创建复制用户与复制槽（避免 WAL 被过早回收）；
  • 备库：hot_standby=on，持续从主库接收并回放 WAL；监控 replication lag 与复制槽状态。
• 切换与演练
  • 定期执行计划内切换（switchover）与故障演练（failover），验证数据一致性与应用重连；
  • 记录切换耗时、数据丢失窗口与回切流程。
• 连接与路由
  • 应用使用 VIP 或连接池/中间件（如 PgBouncer）统一接入；读写分离在中间件或应用层实现，避免直接连备库写入。
• 监控与告警
  • 监控复制延迟、WAL 堆积、连接数、磁盘 IO/空间、VIP 漂移；设置主备角色变更与复制异常的即时告警。
• 安全与网络
  • 限制复制与数据库访问网段，使用强口令/证书；保证主备低时延与稳定网络；跨机房部署时评估同步/异步复制与 RPO/RTO 目标。