PostgreSQL 高可用与负载均衡

一、高可用(High Availability, HA)核心目标**

  1. 最小化停机时间:确保服务在硬件/软件故障时快速恢复。
  2. 数据零丢失:通过同步复制保障数据一致性。
  3. 自动故障转移:无需人工干预切换主节点。

二、主流高可用方案

1. 基于流复制(Streaming Replication)
  • 异步复制:

    • 主库写入后无需等待备库确认(可能丢数据)。
    • 适用场景:对数据一致性要求不高的业务。
  • 同步复制:

    • 主库提交事务需等待至少一个备库确认(synchronous_commit = on + synchronous_standby_names)。

    • 关键配置:

      sql 复制代码
      ALTER SYSTEM SET synchronous_standby_names = 'standby1';
2. 自动故障转移工具
工具 原理 特点
Patroni 基于DCS(etcd/ZooKeeper)协调选举 支持复杂拓扑,与Kubernetes集成最佳
repmgr 轻量级,依赖节点间SSH通信 配置简单,适合中小规模集群
Pgpool-II 集成连接池+故障检测+读写分离 功能全面,但复杂度较高
3. 共享存储方案(如DRBD)
  • 多节点共享同一块磁盘(需分布式文件系统如Ceph)。
  • 风险点:存储单点故障需额外规避。

三、负载均衡实现方式

⚠️ 注意:PostgreSQL 原生不支持负载均衡,需借助中间件。

1. 连接池级负载均衡
  • PgBouncer / pgpool-II:

    • 将客户端连接分发到多个后端PostgreSQL实例。

    • 读写分离 :将读请求路由到备库(需设置default_routing_mode = read in pgpool)。

    • 配置示例(pgpool):

      ini 复制代码
      backend_hostname0 = 'primary'
      backend_port0 = 5432
      backend_hostname1 = 'replica1'
      backend_port1 = 5432
2. 应用层负载均衡
  • 使用 HAProxy / Nginx:

    • 通过TCP代理分发连接(仅适用于读操作)。

    • HAProxy 配置片段:

      conf 复制代码
      frontend pg_read
          bind *:5000
          default_backend pg_replicas
      
      backend pg_replicas
          balance roundrobin
          server replica1 192.168.1.2:5432 check
          server replica2 192.168.1.3:5432 check backup
3. 服务发现(动态扩容)
  • 结合Consul+HAProxy :
    当新备库加入时,Consul自动更新HAProxy后端列表。

四、关键架构图示例

典型高可用+读写分离架构
复制代码
Client → HAProxy (VIP)
        ├──→ PgBouncer (Primary) → Master DB (RW)
        └──→ PgBouncer (Replica) → Standby DB (RO)
                ↑
            Streaming Replication
  • VIP:虚拟IP漂移(Keepalived)
  • 监控:Prometheus + Grafana(监控复制延迟)

五、故障转移(Failover)流程

  1. 检测主库失效(如Patroni通过DCS心跳判断)。

  2. 提升备库为新主库:

bash 复制代码
patronictl failover --candidate replica1 --force
  1. 重配置集群:
  • 更新所有备库的复制源指向新主库。
  • 应用层连接池重定向到新VIP。

六、数据一致性保障

  • 同步复制超时处理 :
    • 若备库无响应,主库自动降级为异步(synchronous_commit = remote_write)。
  • 脑裂(Split-Brain)预防 :
    • 使用Quorum机制(需多数节点确认写入)。
    • Patroni配置ttl(锁租期)避免双主。

七、云原生方案(Kubernetes)

  • Operator框架 :
    • Crunchy Data / Zalando Postgres Operator :
      • 自动创建StatefulSet + 配置流复制。
      • 内置备份、克隆、监控功能。
  • 服务暴露 :
    • 读服务:ClusterIP + 多个Endpoint(指向所有副本)。
    • 写服务:固定指向主库的Headless Service。

八、灾难恢复(Disaster Recovery)

  1. 物理备份 :pg_basebackup + WAL归档(到S3/MinIO)。
  2. 逻辑备份 :pg_dump + 定期验证恢复。
  3. 跨地域复制:使用级联复制或逻辑解码(Debezium)。

九、监控指标清单

类别 关键指标 工具
复制状态 pg_stat_replication lag (bytes) Prometheus + pg_exporter
节点健康 连接数/锁等待/长事务 PGHero
负载均衡 请求分布/错误率 HAProxy Stats

十、常见陷阱

  1. 复制延迟导致读旧数据:
  • 解决方案:应用层使用hot_standby_feedback或强制读主库。
  1. 连接池耗尽:
  • 调整max_connections + 使用PgBouncer复用连接。
  1. 自动故障转移误判:
  • 设置合理的健康检查超时(如Patroni的loop_wait)。

附录:命令速查

bash 复制代码
# 查看复制状态
SELECT client_addr, state, sync_state, write_lag FROM pg_stat_replication;

# 手动提升备库(无工具时)
pg_ctl promote -D /var/lib/postgresql/data
相关推荐
ss2739 分钟前
PG实战笔记 | 04 PostgreSQL市场地位与实际案例
数据库·postgresql
众链网络26 分钟前
Agent 重试的工程解法:幂等、断点续跑与熔断怎么落地
java·前端·数据库·人工智能
oradh35 分钟前
Oracle 索引维护操作总结
数据库·oracle
for_ever_love__36 分钟前
MySQL Online DDL 完全指南:INSTANT/INPLACE/COPY 三种算法、MDL 锁事故与 gh-ost 实战
数据库·mysql·ddl·online·gh-ost·锁表·加字段
for_ever_love__1 小时前
MySQL 子查询、派生表与 CTE 优化:半连接、物化和递归实战
数据库·mysql·优化·as·子查询·with·cte
DBA_G1 小时前
GBase 8c分布式数据库客户端工具 gsql
数据库·分布式
用户5611610232731 小时前
量化笔记程序代码分析,逐笔数据、五档快照和分钟行情代码分析
数据库
房开民1 小时前
通俗总结 Octree(八叉树)
java·服务器·数据库
星云低代码开发平台2 小时前
AI 连接器运行健康度:指标、异常恢复和联调清单
大数据·运维·网络·数据库·人工智能·mcp
鱼宵2 小时前
LangChain4j 生产化改造:记忆落 Redis、向量落 ES,重启再也不丢
数据库·redis·elasticsearch·langchain4j