3分钟扩容PostgreSQL集群：基于Patroni的无缝扩展指南-优快云博客

3分钟扩容PostgreSQL集群：基于Patroni的无缝扩展指南

【免费下载链接】postgresql_cluster PostgreSQL High-Availability Cluster (based on "Patroni" and DCS "etcd" or "consul"). Automating with Ansible. 项目地址: https://gitcode.com/GitHub_Trending/po/postgresql_cluster

你是否遇到过业务高峰期数据库连接数飙升、查询延迟增加的问题？当单节点PostgreSQL无法满足性能需求时，传统的垂直扩容不仅成本高昂，还可能导致服务中断。本文将带你通过Ansible自动化工具，基于Patroni实现PostgreSQL集群的无缝扩容，整个过程无需手动干预主从切换，业务零感知。读完本文后，你将掌握：集群节点规划、Ansible inventory配置、新节点自动加入集群的完整流程，以及扩容后的健康检查方法。

集群扩容前的准备工作

在开始扩容前，需要明确当前集群的架构和资源需求。PostgreSQL集群基于Patroni和分布式配置存储（DCS）如etcd或Consul实现高可用，扩容过程需要确保DCS集群和负载均衡器的协同更新。

环境检查清单

Ansible版本：确保控制节点Ansible版本≥2.17.0，可通过ansible --version验证
SSH免密登录：新节点需配置与现有集群节点的SSH互信，推荐使用项目内置的authorized_keys角色管理密钥
网络连通性：新节点需开放PostgreSQL（默认5432）、Patroni API（默认8008）和DCS服务端口，可参考firewall角色的配置模板
硬件资源：新节点配置建议与现有节点一致，避免性能瓶颈

集群架构示意图

PostgreSQL集群采用一主多从架构，通过Patroni实现自动故障转移，etcd集群存储集群状态信息，HAProxy提供读写分离和负载均衡：

配置Ansible Inventory文件

Ansible通过inventory文件定义集群节点信息，扩容时需在现有配置基础上添加新节点信息。项目提供了完整的示例配置文件inventory.example，可直接复制修改。

添加新节点步骤

复制示例文件：

cp automation/inventory.example automation/inventory

配置新节点参数：在[replica]组下添加新节点IP，并设置new_node=true标记：

[replica]
10.128.64.142 hostname=pgnode02 postgresql_exists=false
10.128.64.143 hostname=pgnode03 postgresql_exists=false
10.128.64.145 hostname=pgnode05 postgresql_exists=false new_node=true  # 新增节点

验证配置：使用Ansible ping模块测试新节点连通性：
```
ansible -i automation/inventory all -m ping
```

关键参数说明：

new_node=true：标记该节点为新增节点，触发扩容专用配置流程
hostname：指定节点在集群中的唯一标识，建议与服务器hostname一致
patroni_tags：可选，用于设置节点属性（如"datacenter=dc2"）实现跨机房部署

执行扩容Playbook

项目提供了专门的扩容剧本add_node.yml，该剧本会自动完成新节点的环境初始化、数据同步和集群配置更新。

执行扩容命令

cd automation
ansible-playbook -i inventory playbooks/add_node.yml

剧本执行流程解析

剧本执行过程分为6个阶段，总耗时约10-15分钟（取决于数据同步量）：

环境准备（第1-25行）：设置集群维护模式，避免扩容期间的故障转移
预检查（第26-157行）：通过pre_checks角色验证节点配置，更新APT缓存并安装依赖包
DCS集群更新（第204-220行）：若使用etcd，自动将新节点加入DCS集群
负载均衡器配置（第222-247行）：更新HAProxy配置并重启服务，参考haproxy角色的模板文件
新节点初始化（第249-283行）：执行系统参数优化（如透明大页禁用、IO调度器设置），可查看sysctl角色的配置
数据同步与集群加入（第317-344行）：通过Patroni自动从主库同步基础备份，无需手动执行pg_basebackup

进度监控：可通过tail -f /var/log/patroni/patroni.log在新节点查看数据同步进度

验证扩容结果

扩容完成后需从集群状态、数据一致性和性能三个维度进行验证。

集群状态检查

查看Patroni集群状态：
```
patronictl -c /etc/patroni/patroni.yml list
```
预期输出应包含新节点，且状态为running
验证DCS状态（以etcd为例）：
```
etcdctl --endpoints=http://10.128.64.140:2379 member list
```
确认新节点已加入etcd集群

数据一致性验证

检查主从同步延迟：在主库执行：

SELECT usename, application_name, state, sync_priority, replay_lag FROM pg_stat_replication;

新节点的replay_lag应接近0

随机数据校验：从新节点查询关键表数据，与主库对比：

# 在主库执行
psql -c "SELECT count(*) FROM important_table;" > /tmp/count.txt
# 在新节点执行
psql -c "SELECT count(*) FROM important_table;" | diff /tmp/count.txt -

无输出表示数据一致

性能监控

推荐部署netdata角色监控新节点性能，重点关注：

CPU使用率：不应持续超过80%
磁盘I/O：数据同步阶段I/O较高属正常，稳定后应与其他从库持平
网络流量：复制流量应与主库写入量匹配

常见问题处理

新节点无法加入集群

症状：Patroni日志显示connection refused连接主库失败
排查步骤：

检查主库pg_hba.conf是否包含新节点IP，可通过postgresql_privs角色重新生成配置
验证新节点到主库的网络连通性：telnet 主库IP 5432
确认主库max_wal_senders参数值足够（建议≥集群节点数+2）

数据同步缓慢

优化方案：

临时调大主库wal_buffers和max_wal_size参数
使用pgbackrest角色配置增量备份，加速同步过程
对于TB级数据量，建议先通过物理备份恢复基础数据，再通过WAL同步增量

负载均衡器未识别新节点

修复方法：

检查HAProxy配置文件/etc/haproxy/haproxy.cfg，确认包含新节点
重启HAProxy服务：systemctl restart haproxy
查看confd角色日志，确认配置自动更新机制正常

总结与最佳实践

通过Ansible自动化剧本和Patroni的协同工作，PostgreSQL集群扩容变得简单高效。关键成功因素包括：

标准化配置：使用项目提供的roles确保所有节点配置一致
灰度扩容：建议每次新增节点数不超过现有节点数的50%，避免DCS集群压力过大
备份先行：扩容前执行一次完整备份，可通过pg_probackup角色实现
监控覆盖：确保新节点纳入现有监控系统，推荐使用netdata角色

未来集群维护可关注项目的更新日志，及时获取新功能和最佳实践指南。如需进一步优化性能，可参考sysctl角色中的内核参数调优建议。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考