PostgreSQL 高可用架构实战：从流复制到 Patroni 集群部署原创

2026-06-25 服务器浏览 (44)

温馨提示：

本文最后更新于 2026-06-25，已超过 77 天没有更新。若文章内的图片失效（无法正常加载），请留言反馈或直接联系我。

PostgreSQL 高可用架构实战：从流复制到 Patroni 集群部署

在现代生产环境中，数据库的高可用性是不可或缺的。PostgreSQL 作为最先进的开源关系型数据库之一，提供了多种高可用方案。本文将从基础到进阶，全面讲解 PostgreSQL 高可用架构的设计与实现。

一、高可用架构基础

1.1 为什么需要高可用

数据库单点故障可能导致：

服务完全中断
数据丢失风险
业务连续性受损
用户信任度下降

一个完善的高可用架构应满足：

故障自动切换：主库宕机时自动选举新主库
数据零丢失：同步复制确保数据完整性
读写分离：利用从库分担读负载
可扩展性：支持水平扩展

1.2 PostgreSQL 高可用方案对比

方案	特点	适用场景
流复制 + 手动切换	简单、原生支持	开发/测试环境
Patroni	自动化、自愈、分布式	生产环境
pgpool-II	连接池 + 负载均衡	读多写少场景
repmgr	管理工具、监控	中小规模集群

二、流复制基础搭建

流复制（Streaming Replication）是 PostgreSQL 高可用的基石。

2.1 主库配置

修改 postgresql.conf：

listen_addresses = '*'
wal_level = replica
max_wal_senders = 10
wal_keep_size = 1024    # MB
hot_standby = on

修改 pg_hba.conf 添加复制用户权限：

# 允许复制连接
host replication replicator 192.168.1.0/24 md5

2.2 从库配置

使用 pg_basebackup 初始化从库：

pg_basebackup -h 192.168.1.10 -D /var/lib/postgresql/data \
  -U replicator -P -v -R --wal-method=stream

参数说明：

-R：自动创建 standby.signal 和 postgresql.auto.conf
--wal-method=stream：使用流复制传输 WAL

2.3 验证复制状态

-- 主库查看复制状态
SELECT * FROM pg_stat_replication;

-- 从库查看恢复状态
SELECT * FROM pg_stat_wal_receiver;

三、Patroni 集群部署

Patroni 是目前最流行的 PostgreSQL 高可用管理工具，它使用分布式一致性算法（etcd/Consul/ZooKeeper）实现自动故障切换。

3.1 架构设计

一个典型的 Patroni 集群包含：

PostgreSQL 节点：3 个以上节点（一主多从）
DCS（分布式配置存储）：etcd 或 Consul
Patroni：运行在每个节点上的管理进程
HAProxy：负载均衡和连接路由

3.2 安装与配置

安装 Patroni：

pip install patroni[etcd]

Patroni 配置文件 /etc/patroni/patroni.yml：

scope: pg-cluster
namespace: /db/
name: pg-node1

restapi:
  listen: 0.0.0.0:8008
  connect_address: 192.168.1.10:8008

etcd:
  host: 192.168.1.100:2379

bootstrap:
  dcs:
    ttl: 30
    loop_wait: 10
    retry_timeout: 10
    maximum_lag_on_failover: 1048576
    postgresql:
      use_pg_rewind: true
      parameters:
        wal_level: replica
        hot_standby: on
        max_wal_senders: 10
        max_replication_slots: 10
        wal_log_hints: on

postgresql:
  listen: 0.0.0.0:5432
  connect_address: 192.168.1.10:5432
  data_dir: /var/lib/postgresql/15/main
  bin_dir: /usr/lib/postgresql/15/bin
  authentication:
    replication:
      username: replicator
      password: secure_password
    superuser:
      username: postgres
      password: super_secure_password

3.3 启动集群

# 在每个节点启动 Patroni
systemctl start patroni

# 查看集群状态
patronictl -c /etc/patroni/patroni.yml list

# 输出示例：
# + Cluster: pg-cluster (734234234) ----+----+-----------+
# | Member    | Host          | Role    | State | Lag     |
# +-----------+---------------+---------+-------+---------+
# | pg-node1  | 192.168.1.10  | Leader  | running | 0      |
# | pg-node2  | 192.168.1.11  | Replica | running | 0      |
# | pg-node3  | 192.168.1.12  | Replica | running | 0      |
# +-----------+---------------+---------+-------+---------+

四、HAProxy 负载均衡

HAProxy 作为前端代理，将读写请求路由到正确的 PostgreSQL 节点。

global
    maxconn 1000

defaults
    mode tcp
    timeout connect 5s
    timeout client 30s
    timeout server 30s

frontend pg_frontend
    bind *:5000
    default_backend pg_write

    # 读请求路由到从库
    acl read_only path_end -i /read
    use_backend pg_read if read_only

backend pg_write
    option httpchk GET /master
    server pg-node1 192.168.1.10:5432 check port 8008
    server pg-node2 192.168.1.11:5432 check port 8008
    server pg-node3 192.168.1.12:5432 check port 8008

backend pg_read
    option httpchk GET /replica
    server pg-node2 192.168.1.11:5432 check port 8008
    server pg-node3 192.168.1.12:5432 check port 8008

五、故障切换测试

5.1 模拟主库故障

# 停止主库 PostgreSQL
systemctl stop postgresql@15-main

# Patroni 自动检测并切换
patronictl -c /etc/patroni/patroni.yml list

# 输出显示新 Leader 已选举

5.2 恢复原主库

# 启动原主库
systemctl start postgresql@15-main

# Patroni 自动将其加入集群作为从库
patronictl -c /etc/patroni/patroni.yml list

六、监控与告警

# 使用 patronictl 查看详细状态
patronictl -c /etc/patroni/patroni.yml topology

# 检查复制延迟
SELECT
    application_name,
    state,
    sync_state,
    pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) AS replay_lag
FROM pg_stat_replication;