构建企业级PostgreSQL高可用集群：基于etcd与Patroni的离线部署实战

1. 离线环境准备：从零搭建企业级数据库集群的基础

在金融、政务等对数据安全要求极高的场景中，我们经常需要在内网隔离环境下部署数据库系统。这种环境下，传统的在线安装方式完全失效，必须采用离线部署方案。我去年参与某银行核心系统升级时，就遇到过这样的挑战——整个数据中心完全隔离，连最基本的yum命令都无法使用。

离线部署的核心在于提前准备好所有依赖组件。根据我的经验，一个完整的PostgreSQL高可用集群需要准备以下软件包：

• PostgreSQL 11.11源码包（约30MB）
• etcd-v3.4.7分布式键值存储（约40MB）
• Patroni-1.6.1集群管理工具（约5MB）
• HAProxy-1.7.14负载均衡器（约2MB）
• Keepalived-1.4.5虚拟IP管理（约1MB）

实际操作中，我建议创建一个统一的离线资源目录结构：

/pghaenv/ ├── postgresql_env/ # PostgreSQL依赖的rpm包 ├── patroni_env/ # Python依赖的whl文件 ├── postgresql-11.11.tar.gz ├── etcd-v3.4.7-linux-amd64.tar.gz ├── patroni-1.6.1.tar.gz └── HAProxyKeepalived.tar.gz

在准备过程中最容易踩的坑是依赖包版本冲突。有次我在某政务云项目上，就因openssl版本不兼容导致整个安装流程卡住。后来总结的经验是：所有rpm包必须用--nodeps --force参数强制安装：

cd /pghaenv/postgresql_env/ rpm -ivh *.rpm --nodeps --force

2. PostgreSQL源码安装：定制化配置的最佳实践

源码安装虽然比二进制包复杂，但能获得更好的性能调优空间。在金融级场景中，我通常会做这些关键配置：

块大小优化是第一个要注意的点。对于OLTP系统，8KB的默认块大小往往不是最佳选择。通过实测发现，当单行数据平均大小在2KB左右时，16KB的块大小能使TPC-C性能提升约18%：

./configure --prefix=/software/pgsql \ --with-blocksize=16 \ --with-wal-blocksize=16 \ --with-wal-segsize=64

环境变量配置经常被新手忽略。有次巡检发现某生产环境psql命令找不到，就是因为PATH没设置正确。正确的做法是在postgres用户的.bash_profile中加入：

PGHOME=/software/pgsql export PGHOME PATH=$PATH:$PGHOME/bin

初始化参数调优直接影响数据库稳定性。在postgresql.conf中，这几个参数需要特别注意：

listen_addresses = '*' # 允许所有IP连接 wal_level = logical # 逻辑复制必备 max_wal_senders = 10 # 根据备库数量调整 hot_standby = on # 开启备库读写 synchronous_commit = remote_apply # 金融级数据一致性要求

3. etcd集群部署：分布式一致性的保障

etcd作为Patroni的后端存储，其稳定性直接决定整个集群的可靠性。在政务系统部署中，我总结出这些关键点：

集群初始化参数需要特别注意--initial-cluster-state。有次故障恢复时就因误设为existing导致集群无法启动。正确的三节点配置示例：

# 节点1 (192.168.52.121) /opt/etcd-v3.4.7/etcd --name etcd_01 \ --listen-peer-urls http://192.168.52.121:2380 \ --advertise-client-urls http://192.168.52.121:2379 \ --initial-cluster etcd_01=http://192.168.52.121:2380,etcd_02=http://192.168.52.122:2380,etcd_03=http://192.168.52.123:2380 \ --initial-cluster-state new

服务化部署是生产环境必备。通过systemd管理etcd服务时，我发现Type=forking模式最稳定：

[Unit] Description=etcd After=network.target [Service] Type=forking ExecStart=/opt/etcd-v3.4.7/start_etcd.sh

集群健康检查不能仅靠etcdctl endpoint status。在某次金融系统演练中，我编写了这样的检查脚本：

#!/bin/bash ETCD_ENDPOINTS="192.168.52.121:2379,192.168.52.122:2379,192.168.52.123:2379" etcdctl --endpoints=$ETCD_ENDPOINTS endpoint health --write-out=table etcdctl --endpoints=$ETCD_ENDPOINTS member list --write-out=table

4. Patroni集群配置：自动故障转移的实现精髓

Patroni的配置文件中藏着许多魔鬼细节。在政务云项目中，这些参数配置让我踩过不少坑：

关键时间参数需要根据业务特点调整。对于交易系统，我通常这样设置：

dcs: ttl: 30 # 租约超时时间(秒) loop_wait: 10 # 主库检查间隔 retry_timeout: 10 # 重试超时 maximum_lag_on_failover: 1048576 # 允许的滞后字节数

PostgreSQL参数的继承关系容易混淆。在patroni.yml中定义的参数会覆盖postgresql.conf的设置：

postgresql: parameters: max_connections: 500 # 会覆盖配置文件 shared_buffers: 4GB # 重要参数必须显式声明 work_mem: 16MB # 每个查询的工作内存

Watchdog配置是防止脑裂的最后防线。在金融系统中我推荐使用自动模式：

watchdog: mode: automatic # 自动触发保护 device: /dev/watchdog safety_margin: 5 # 超时缓冲秒数

服务启动顺序有严格依赖。正确的流程应该是：

1. 先启动所有etcd节点
2. 检查etcd集群状态
3. 启动Patroni服务（会自动初始化PostgreSQL）

systemctl start etcd /opt/etcd-v3.4.7/etcdctl endpoint status systemctl start patroni

5. 高可用接入层：HAProxy+Keepalived实战

接入层的稳定性直接影响业务连续性。在银行核心系统中，我采用这样的架构：

Keepalived配置要注意vrrp_instance的优先级设置。主节点应该设置为最高：

# 主节点(192.168.52.121) priority 100 state MASTER # 备节点1(192.168.52.122) priority 90 state BACKUP # 备节点2(192.168.52.123) priority 80 state BACKUP

HAProxy的健康检查需要与Patroni的REST API配合。这是经过生产验证的配置：

listen master bind 192.168.52.120:5000 option httpchk OPTIONS /master http-check expect status 200 server db01 192.168.52.121:5432 check port 8008 server db02 192.168.52.122:5432 check port 8008 server db03 192.168.52.123:5432 check port 8008

内核参数调整经常被忽视。必须开启ip_nonlocal_bind才能绑定虚拟IP：

echo "net.ipv4.ip_nonlocal_bind = 1" >> /etc/sysctl.conf sysctl -p

6. 业务连续性验证：从理论到实践的完整闭环

部署完成后的验证环节至关重要。在政务系统验收时，我们设计了这些测试场景：

主库故障转移测试需要模拟真实故障。我常用的方法是直接kill主库进程：

# 查看当前主库 patronictl -c /software/patroni/patroni.yml list # 在主库节点执行 kill -9 `head -1 /software/pgsql/data/postmaster.pid` # 观察VIP切换和新的主库选举 tail -f /software/patroni/patroni.log

数据一致性验证要用到pg_checksums工具。在某次金融审计中，我们这样检查：

pg_checksums --enable -D /software/pgsql/data pg_checksums --check -D /software/pgsql/data

性能基准测试推荐使用pgbench。执行前需要初始化测试数据：

pgbench -i -s 100 -h 192.168.52.120 -p 5000 pgbench -c 50 -j 4 -T 300 -h 192.168.52.120 -p 5000

7. 运维监控体系的建立

完善的监控是生产环境的生命线。在银行项目中，我们采用这样的方案：

Patroni自带的监控接口可以提供基础数据：

curl http://192.168.52.121:8008/patroni

HAProxy的统计页面能直观展示负载情况：

# 访问地址 http://192.168.52.121:7000/stats

自定义告警规则需要关注这些关键指标：

• etcd leader变化次数
• Patroni切换事件
• 复制延迟时间
• 连接数使用率

8. 常见故障排查手册

在实际运维中，这些问题最常遇到：

脑裂场景的处理需要严格按照流程：

1. 确认etcd集群健康状态
2. 检查各节点Patroni日志
3. 手动执行failover命令

patronictl -c /software/patroni/patroni.yml failover

复制中断恢复的步骤：

1. 检查pg_wal目录空间
2. 验证网络连通性
3. 必要时使用pg_rewind同步

pg_rewind --target-pgdata=/software/pgsql/data \ --source-server="host=192.168.52.121 port=5432 user=postgres"

连接池耗尽的解决方案：

1. 调整max_connections参数
2. 配置pgbouncer中间件
3. 优化长事务

在最近一次政务云扩容项目中，这套架构成功支撑了每秒3000+的政务事项办理请求，全年可用性达到99.99%。特别是在某次机房电力故障中，整个集群在8秒内完成自动切换，业务完全无感知。