PostgreSQL在CentOS中的高可用方案

PostgreSQL 在 CentOS 的高可用方案总览

在 CentOS 上，生产级高可用通常采用“DCS（如 etcd）+ Patroni 管理主从与故障切换”，前端通过 HAProxy/Keepalived 提供统一接入与 VIP 漂移，必要时叠加 Pgpool‑II 实现读写分离与会话级故障转移。该组合具备自动选主、快速切换、可观测与可运维性强等优点，适合大多数业务场景。

方案一 推荐组合 etcd + Patroni + HAProxy + Keepalived

• 组件分工
  • etcd：分布式一致性存储，保存集群状态与会话租约（建议 3/5/7 节点奇数部署）。
  • Patroni：接管 PostgreSQL 生命周期（init/start/stop/failover/switchover），通过 DCS 实现选主与配置下发。
  • HAProxy：5432 端口的四层转发与健康检查，支持读写分离（例如将 5432 转发到当前主，5433 转发到所有副本）。
  • Keepalived：提供 VIP，实现客户端对数据库地址的无感漂移。
• 关键配置要点（Patroni 片段）
  • 复制与一致性
    • wal_level=replica，synchronous_commit=remote_write，synchronous_standby_names 指向目标副本（如 “node2,node3”）。
    • 启用复制槽与回滚加速：use_slots=true，use_pg_rewind=true。
    • 资源与 WAL：max_wal_senders≥4，max_replication_slots≥4，wal_keep_segments 或 wal_keep_size 合理设置，archive_mode=on 并配置 archive_command。
  • 连接与安全
    • 创建复制用户 replicator，在 pg_hba.conf 放行 replication 网段（如 192.168.1.0/24 md5）。
    • 监听地址 listen_addresses=‘*’，对外暴露 5432；Patroni REST API 建议仅内网开放（如 8008）。
• 接入层配置要点
  • HAProxy 健康检查：option pgsql-check user replicator；后端区分 master 与 replicas，分别指向 5432/5433。
  • Keepalived：state/priority 区分主备，virtual_ipaddress 配置业务 VIP，nopreempt/advert_int 合理设置，VRRP 认证与接口按现场调整。
• 适用场景
  • 需要自动故障转移、读写分离、统一接入与 VIP 漂移的在线业务；对 RTO/RPO 有明确要求的中大型集群。

方案二 传统高可用 Pacemaker + Corosync + Patroni

• 思路与取舍
  • 以 Pacemaker/Corosync 作为集群资源管理器，Patroni 负责 PostgreSQL 内部复制与本地实例管理；DCS 仍用于跨节点选主与状态协同。
  • 优点：与既有 Pacemaker 体系兼容；缺点：组件多、调优复杂，通常仅在已有 Pacemaker 环境中采用。
• 关键配置要点
  • Corosync：配置 totem/transport、nodelist、quorum、日志；确保节点间网络稳定与冗余。
  • Pacemaker：通过 ocf:heartbeat:pgsql 等资源代理管理实例，定义监控、启动/停止、迁移策略与约束。
  • Patroni：保持与方案一相近的复制参数与 DCS 配置，确保 Patroni 与 Pacemaker 的职责边界清晰（Patroni 管库，Pacemaker 管资源与 VIP）。

方案三 中间件型 Pgpool‑II 实现读写分离与会话故障转移

• 适用场景
  • 需要在连接层做读写分离、连接池、负载均衡，并对后端节点做健康检查与故障转移的场景；可与 Patroni/Keepalived 组合使用（Patroni 管主从与切换，Pgpool‑II 管连接与会话）。
• 关键配置要点
  • backend_hostnameN/backend_portN 配置后端节点；load_balance_mode=on；开启健康检查。
  • 配置 failover_command/recovery_command 脚本，实现主备切换后的元数据与连接清理；权重与连接池参数按并发调优。

方案四 云原生路线 CloudNativePG（Kubernetes）

• 适用场景
  • 业务运行在 Kubernetes 中，期望以 Operator 管理 PostgreSQL 全生命周期、自动故障转移与自愈、支持同步复制与跨集群灾备。
• 能力要点
  • 基于原生流复制的一主多备；支持基于仲裁/优先级的同步复制；提供集群自愈、滚动升级、备份/恢复与跨地域灾备能力。

落地实施与运维要点

• 基础与网络
  • 建议 3 台及以上数据库节点 + 3/5/7 节点 etcd；各节点时间同步（如 chrony/ntpd）；防火墙放行 5432/8008/2379 等必要端口；数据库与应用分离部署。
• 复制与一致性
  • 根据业务选择：异步（RTO 优先）或同步（RPO 优先，建议 quorum 同步）；合理设置 synchronous_standby_names、synchronous_commit、max_wal_senders、max_replication_slots、wal_keep_segments/wal_keep_size、archive_mode/archive_command。
• 切换与回滚
  • 启用 use_pg_rewind 加速新主回滚；使用 Patroni 的 switchover/failover 命令执行计划内/外切换，切换前确认复制延迟与同步备机数量。
• 接入与健康检查
  • HAProxy 使用基于用户的 pgsql-check 健康检查；为应用提供 VIP 或连接串变更策略，避免直连具体节点；监控 Patroni DCS 租约、复制延迟、WAL 堆积与连接数。
• 备份与演练
  • 定期执行 pg_basebackup/WAL 归档与逻辑/物理备份；定期演练故障切换与恢复流程，验证 RTO/RPO 指标与告警有效性。