PostgreSQL在CentOS上的高可用性方案

PostgreSQL 在 CentOS 上的高可用方案

一、方案总览与适用场景

• 生产上常用且成熟的路径主要有三类：
  1. Patroni + etcd/consul/zookeeper + 流复制 + VIP/负载均衡（自动化程度高、可自动故障切换与重初始化）；
  2. Pacemaker + Corosync（传统集群栈，资源代理控制实例与 VIP，适合已有集群管理经验的团队）；
  3. 共享存储/DRBD（共享磁盘或块设备镜像，切换快，但共享存储成为单点）。
• 复制与一致性要点：PostgreSQL 以WAL 流复制为主，支持异步/同步与级联复制；同步提交可显著降低数据丢失风险但会增加提交时延；建议结合复制插槽与WAL 归档保障恢复与稳定性。

二、方案一 Patroni + etcd + 流复制 + VIP/HAProxy（推荐）

• 架构要点
  • 3 节点构成最小高可用集：每个节点运行 PostgreSQL + Patroni + etcd，Patroni 将实例状态写入 etcd（Raft），实现主选举与自动故障切换；
  • 对外提供VIP或经由 HAProxy 暴露读写端口，读写分离可在 HAProxy 层实现（写主、读从）。
• 关键配置示例（Patroni DCS 与 PostgreSQL 参数）
  • etcd 集群：三节点分别配置 ETCD_NAME、LISTEN_CLIENT_URLS/ADVERTISE_CLIENT_URLS、LISTEN_PEER_URLS、INITIAL_CLUSTER 等，形成 3 节点 etcd 集群；
  • Patroni 关键项：
    • bootstrap.dcs：use_pg_rewind=true、use_slots=true；
    • PostgreSQL 参数：wal_level=replica、max_wal_senders、max_replication_slots、hot_standby=on；
    • 同步提交示例：synchronous_commit=remote_write、synchronous_standby_names=‘node2,node3’（按业务选择级别与数量）。
• 故障切换与验证
  • 停止主库 Patroni 或宕机，观察 etcd 选主与 Patroni 将新主提升；
  • 通过 VIP/HAProxy 连接数据库，确认写操作在新主生效、读操作在从库返回；
  • 演练后执行 pg_rewind 旧主重加入，确保集群可回切。
• 适用场景
  • 需要自动化运维、快速切换、多节点扩展与读写分离的在线业务。

三、方案二 Pacemaker + Corosync 集群

• 架构要点
  • 2 节点数据库 + Pacemaker + Corosync 提供资源管理与仲裁；
  • 通过 pcs 配置资源：Master/Slave Set（pgsql RA） 管理实例角色切换，IPaddr2 提供 VIP，可配合 STONITH 做防护。
• 快速步骤（CentOS 7 示例）
  • 安装组件：pacemaker pcs psmisc policycoreutils-python postgresql-server；
  • 启用 pcsd 并认证集群节点；
  • 创建集群（如：pcs cluster setup --name pgcluster node1 node2）；
  • 启动集群并配置资源（pgsql 主从资源、VIP 资源、约束与 fencing）；
  • 验证 corosync/pacemaker 状态与资源运行节点。
• 适用场景
  • 倾向传统集群栈、已有 Pacemaker 运维体系、需要细粒度资源控制与仲裁策略的场景。

四、方案三 共享存储或 DRBD 的失效切换

• 架构要点
  • 共享磁盘/NAS 或 DRBD 在主机间镜像数据，主库故障时备机挂载同一存储继续服务；
  • 切换逻辑简单、切换时间短，但共享存储本身为单点，需配合多路径、存储级高可用与严格演练。
• 适用场景
  • 对切换时延极敏感且能接受共享存储复杂度的环境；或已有成熟的SAN/NAS 体系。

五、关键配置与运维要点

• 复制与一致性
  • 基础：主库 wal_level=replica、max_wal_senders、hot_standby=on；备库通过 primary_conninfo 与（可选）restore_command 接入流复制；
  • 稳定性：启用复制插槽（primary_slot_name）避免 WAL 过早回收；必要时配置 WAL 归档与 restore_command；
  • 一致性：按业务选择 synchronous_commit（如 remote_write/remote_apply）与 synchronous_standby_names，在数据安全性与提交时延间平衡。
• 监控与演练
  • 复制监控：使用 pg_stat_replication 查看同步状态与延迟；
  • 延迟评估：对比 pg_current_wal_lsn() 与 pg_last_wal_replay_lsn() 评估备库回放滞后；
  • 定期演练：故障注入、主备切换、回切与备份恢复演练，验证 RTO/RPO 与流程有效性。
• 负载均衡与连接管理
  • 读写分离与连接池：在 HAProxy 或 PgBouncer 层做读写路由与会话保持；对强一致读（如 SELECT … FOR UPDATE）强制走主库。