7步构建PostgreSQL高可用集群：repmgr实战指南
项目地址: https://gitcode.com/gh_mirrors/re/repmgr 你是否还在为PostgreSQL主从切换焦头烂额？面对数据库故障只能手动介入恢复？本文将带你通过7个实战步骤，使用repmgr构建一套稳定可靠的PostgreSQL高可用集群，实现自动故障转移与无缝切换。读完本文你将掌握：
- repmgr集群架构设计与环境准备
- 主从节点快速部署与配置
- 自动故障转移机制实现
- 集群监控与维护最佳实践
- 常见故障排查与性能优化
1. repmgr核心价值与架构解析
repmgr是EnterpriseDB开发的轻量级PostgreSQL（Postgres）复制管理工具，通过增强PostgreSQL内置的流复制能力，提供了主备切换、故障转移、集群监控等核心功能。最新版本5.5.x支持PostgreSQL 13-17，采用GNU GPL 3开源协议。
1.1 传统复制方案痛点
| 痛点 | 手动管理 | repmgr解决方案 |
|---|---|---|
| 主库故障恢复 | 平均30分钟+ | 自动检测，秒级切换 |
| 备库延迟监控 | 脚本轮询，准确性低 | 内置监控，毫秒级精度 |
| 主备切换流程 | 10+步骤，易出错 | 单命令完成，自动更新元数据 |
| 集群状态可视化 | 无统一视图 | repmgr cluster show直观展示 |
| 脑裂预防 | 依赖第三方工具 | 内置见证节点与网络分区检测 |
1.2 典型集群架构
2. 环境准备与安装配置
2.1 系统要求
| 组件 | 推荐配置 | 最低配置 |
|---|---|---|
| CPU | 4核8线程 | 2核4线程 |
| 内存 | 16GB | 8GB |
| 存储 | SSD 500GB | HDD 200GB |
| 网络 | 10Gbps | 1Gbps |
| 操作系统 | CentOS 8/Ubuntu 20.04 | CentOS 7/Ubuntu 18.04 |
| PostgreSQL版本 | 14-17 | 13 |
2.2 源码安装步骤
# 安装依赖
yum install -y gcc make libpq-devel postgresql14-devel libxslt-devel libxml2-devel
# 获取源码
git clone https://gitcode.com/gh_mirrors/re/repmgr
cd repmgr
# 编译安装
./configure && make install
# 验证安装
repmgr --version
# repmgr 5.5.0
2.3 配置文件详解
创建/etc/repmgr.conf，核心配置参数如下：
# 必选参数
node_id=1 # 节点唯一ID（1-32767）
node_name='node1' # 节点名称（避免使用'primary'/'standby'等角色相关名称）
conninfo='host=192.168.1.11 user=repmgr dbname=repmgr connect_timeout=2' # 连接信息
data_directory='/var/lib/postgresql/14/main' # 数据目录
# 可选参数
replication_user='repmgr' # 复制用户
use_replication_slots=yes # 使用复制槽
log_level='INFO' # 日志级别
log_file='/var/log/repmgr/repmgrd.log' # 日志文件
pg_bindir='/usr/pgsql-14/bin' # PostgreSQL二进制目录
priority=100 # 故障转移优先级（0-100，0表示不可提升）
failover='automatic' # 故障转移模式
3. 集群部署实战
3.1 初始化主节点
# 创建repmgr用户和数据库
sudo -u postgres psql -c "CREATE USER repmgr SUPERUSER;"
sudo -u postgres psql -c "CREATE DATABASE repmgr OWNER repmgr;"
# 配置pg_hba.conf
echo "host replication repmgr 192.168.1.0/24 trust" >> $PGDATA/pg_hba.conf
echo "host repmgr repmgr 192.168.1.0/24 trust" >> $PGDATA/pg_hba.conf
sudo -u postgres pg_ctl reload
# 注册主节点
repmgr -f /etc/repmgr.conf primary register
# 验证主节点状态
repmgr -f /etc/repmgr.conf cluster show
# 输出应显示主节点状态为"running"
3.2 克隆备节点
# 在备节点执行克隆（--dry-run先检查环境）
repmgr -h 192.168.1.11 -U repmgr -d repmgr -f /etc/repmgr.conf standby clone --dry-run
# 实际克隆操作
repmgr -h 192.168.1.11 -U repmgr -d repmgr -f /etc/repmgr.conf standby clone
# 启动备库
sudo -u postgres pg_ctl -D /var/lib/postgresql/14/main start
# 注册备节点
repmgr -f /etc/repmgr.conf standby register
# 验证集群状态
repmgr -f /etc/repmgr.conf cluster show
# 输出应显示2个节点，备节点状态为"running"
3.3 配置见证节点（可选）
# 在见证节点创建数据库
sudo -u postgres createdb repmgr -O repmgr
# 注册见证节点
repmgr -f /etc/repmgr.conf witness register --upstream-node-id=1
# 验证见证节点状态
repmgr -f /etc/repmgr.conf cluster show
# 输出应显示见证节点角色为"witness"
4. 自动故障转移配置
4.1 repmgrd服务配置
# repmgr.conf中添加自动故障转移参数
failover='automatic'
promote_command='repmgr standby promote -f /etc/repmgr.conf'
follow_command='repmgr standby follow -f /etc/repmgr.conf --upstream-node-id=%n'
standby_disconnect_on_failover=true
primary_visibility_consensus=true
4.2 启动repmgrd服务
# 启动repmgrd（所有节点）
repmgrd -f /etc/repmgr.conf --daemonize
# 验证服务状态
repmgr -f /etc/repmgr.conf service status
# 输出应显示repmgrd状态为"running"
4.3 故障转移流程解析
5. 集群监控与维护
5.1 关键监控命令
| 命令 | 用途 | 示例输出 |
|---|---|---|
repmgr cluster show | 集群状态概览 | ID|Name|Role|Status |
repmgr node check | 节点健康检查 | 连接性/复制延迟/权限等 |
repmgr cluster crosscheck | 节点间连接检查 | 矩阵形式展示节点互通性 |
repmgr service status | repmgrd服务状态 | 各节点repmgrd运行情况 |
5.2 日常维护任务
# 手动切换主备（测试用）
repmgr -f /etc/repmgr.conf standby switchover --siblings-follow
# 重新加入故障节点
repmgr -f /etc/repmgr.conf node rejoin --node-id=1
# 升级repmgr元数据
repmgr -f /etc/repmgr.conf upgrade
# 清理旧WAL文件
repmgr -f /etc/repmgr.conf cluster cleanup --node-id=1
5.3 性能优化建议
-
复制优化
# postgresql.conf max_wal_senders=10 wal_keep_size=1GB wal_compression=on -
网络优化
# repmgr.conf ssh_options='-o ConnectTimeout=10 -o ServerAliveInterval=5' -
监控优化
# repmgr.conf monitoring_history=yes monitor_interval_secs=2
6. 故障排查与常见问题
6.1 复制延迟过高
| 可能原因 | 解决方案 |
|---|---|
| 网络带宽不足 | 升级网络或启用WAL压缩 |
| 备库IO性能差 | 迁移至SSD或调整shared_buffers |
| 大事务阻塞 | 拆分大事务或使用pg_repack |
| 备库查询过载 | 增加只读副本分流查询 |
6.2 故障转移失败
# 查看repmgrd日志
tail -f /var/log/repmgr/repmgrd.log
# 常见原因：
# 1. 备库与主库LSN差距过大
# 解决方案：重新克隆备库
repmgr standby clone --force
# 2. 权限不足
# 解决方案：确保repmgr用户有足够权限
psql -c "GRANT ALL PRIVILEGES ON SCHEMA repmgr TO repmgr;"
6.3 脑裂问题处理
# 检测脑裂
repmgr cluster crosscheck
# 解决脑裂（手动干预）
repmgr cluster cleanup --force --node-id=1
repmgr standby follow --upstream-node-id=2
7. 进阶功能与最佳实践
7.1 级联复制配置
# 在级联备库执行
repmgr standby clone --upstream-node-id=2
repmgr standby register --upstream-node-id=2
7.2 定期备份策略
# 结合pg_basebackup与repmgr
repmgr standby clone --backup-method=basebackup --pg-basebackup-options="--compress=9"
7.3 安全加固建议
-
最小权限原则
-- 创建非超级用户repmgr CREATE USER repmgr WITH REPLICATION; GRANT pg_monitor TO repmgr; -
SSL加密复制
# repmgr.conf conninfo='host=192.168.1.11 sslmode=verify-full sslrootcert=/etc/ssl/certs/rootCA.pem' -
审计日志
# postgresql.conf log_statement='ddl' log_min_duration_statement=1000
总结与展望
通过本文介绍的7个步骤，你已掌握使用repmgr构建PostgreSQL高可用集群的核心技能。repmgr不仅简化了主备管理，更通过自动化故障转移大幅提升了系统可用性。建议进一步深入：
- 探索repmgr与Barman的集成备份方案
- 研究跨区域灾备架构设计
- 测试不同故障场景下的恢复时间目标(RTO)
收藏本文，关注后续《repmgr高级运维：从故障演练到性能调优》系列文章，让你的PostgreSQL集群运维更上一层楼！
附录：参考资源
- repmgr官方文档：https://repmgr.org/docs/current/index.html
- PostgreSQL流复制：https://www.postgresql.org/docs/current/warm-standby.html
- repmgr GitHub仓库：https://gitcode.com/gh_mirrors/re/repmgr
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
