3分钟搞定PostgreSQL主从切换：repmgr备用节点无缝跟随新主节点实战指南
项目地址: https://gitcode.com/gh_mirrors/re/repmgr 你还在手动切换PostgreSQL主从节点？
当主节点故障时，传统的PostgreSQL主从切换需要手动修改配置文件、重启服务、验证数据一致性，整个过程至少30分钟，期间业务中断风险极高。而使用repmgr的standby follow功能，只需一条命令即可让备用节点在3分钟内完成新主节点的自动跟随，实现近乎零停机的故障转移。
本文将系统讲解repmgr备用节点跟随新主节点的核心原理、操作步骤、配置优化及故障排除，读完你将掌握：
- 3步完成备用节点跟随配置
- 自动故障转移后的节点自愈方案
- 90%用户会踩的5个配置陷阱及规避方法
- 生产环境必备的监控告警配置
技术原理：备用节点如何"找到"新主节点？
repmgr通过维护集群元数据和实时监控实现备用节点的智能跟随。当主节点发生故障并完成故障转移后，备用节点需要执行以下关键步骤：
关键技术点包括：
- 元数据同步：repmgrd通过定期同步
repmgr.nodes表维护集群拓扑 - LSN位置验证：确保备用节点与新主节点的WAL位置兼容
- 配置自动更新：动态修改
primary_conninfo参数无需人工干预 - 服务无缝重启：PostgreSQL 13+支持
SIGHUP重载配置，避免服务中断
实战操作：3步实现备用节点自动跟随
环境准备与前置检查
假设我们已构建如下三节点集群：
| 节点ID | 角色 | 主机名 | IP地址 | PostgreSQL版本 | repmgr版本 |
|---|---|---|---|---|---|
| 1 | 原主节点 | node1 | 192.168.1.1 | 16.2 | 5.5 |
| 2 | 新主节点 | node2 | 192.168.1.2 | 16.2 | 5.5 |
| 3 | 备用节点 | node3 | 192.168.1.3 | 16.2 | 5.5 |
在执行跟随操作前，需在备用节点(node3)执行以下检查：
# 验证与新主节点的网络连通性
psql -h node2 -U repmgr -d repmgr -c "SELECT version();"
# 检查数据同步状态
repmgr -f /etc/repmgr.conf node check --replication-lag
# 执行预演操作(强烈推荐)
repmgr -f /etc/repmgr.conf standby follow --dry-run
预演成功的输出应包含：INFO: all prerequisites for "standby follow" are met
核心配置文件优化
repmgr.conf关键参数配置（node3上）：
# 基础配置
node_id=3
node_name='node3'
conninfo='host=node3 user=repmgr dbname=repmgr connect_timeout=2'
data_directory='/var/lib/postgresql/16/main'
# 跟随新主节点专用配置
standby_follow_timeout=60 # 等待新主节点超时时间
standby_follow_restart=false # PostgreSQL 13+建议设为false
primary_follow_timeout=120 # 主节点响应超时时间
# repmgrd自动故障转移配置
failover='automatic'
follow_command='repmgr standby follow -f /etc/repmgr.conf --upstream-node-id=%n'
promote_command='repmgr standby promote -f /etc/repmgr.conf'
⚠️ 注意：
standby_follow_restart参数在PostgreSQL 13+版本应设为false，利用SIGHUP实现配置重载，避免服务重启；而12及以下版本必须设为true。
执行跟随操作与结果验证
当node1故障，node2已晋升为新主节点后，在node3执行：
# 基本跟随命令
repmgr -f /etc/repmgr.conf standby follow
# 指定上游节点ID(推荐)
repmgr -f /etc/repmgr.conf standby follow --upstream-node-id=2
成功执行的输出示例：
INFO: changing node 3's primary to node 2
NOTICE: restarting server using "pg_ctl -l /var/log/postgresql/startup.log -w -D '/var/lib/postgresql/16/main' restart"
waiting for server to shut down......... done
server stopped
waiting for server to start.... done
server started
NOTICE: STANDBY FOLLOW successful
DETAIL: node 3 is now attached to node 2
执行后验证集群状态：
repmgr -f /etc/repmgr.conf cluster show
# 预期输出
ID | Name | Role | Status | Upstream | Location | Priority | Timeline | Connection string
----+-------+---------+-----------+----------+----------+----------+----------+----------------------------------------
1 | node1 | primary | - failed | | default | 100 | 1 | host=node1 dbname=repmgr user=repmgr
2 | node2 | primary | * running | | default | 100 | 2 | host=node2 dbname=repmgr user=repmgr
3 | node3 | standby | running | node2 | default | 100 | 2 | host=node3 dbname=repmgr user=repmgr
高级配置：构建自愈式高可用集群
自动故障转移的跟随配置
要实现故障转移后备用节点自动跟随，需配置repmgrd服务并设置follow_command：
# repmgr.conf中添加
repmgrd_pid_file='/var/run/repmgrd.pid'
monitor_interval_secs=2
reconnect_attempts=6
reconnect_interval=10
# 自动跟随命令(关键)
follow_command='repmgr standby follow -f /etc/repmgr.conf --upstream-node-id=%n'
启动repmgrd服务：
systemctl enable --now repmgrd
systemctl status repmgrd
repmgrd日志验证（/var/log/repmgr/repmgrd.log）：
[2025-09-08 15:44:12] [INFO] node 3 monitoring upstream node 2 in normal state
[2025-09-08 15:44:14] [INFO] replication lag on node 3 is 0 bytes
网络分区场景的智能处理
在多数据中心部署时，通过location配置实现分区感知：
# DC1节点配置
location='dc1'
primary_visibility_consensus=true
# DC2节点配置
location='dc2'
priority=50 # 降低跨区域晋升优先级
当发生网络分区时，repmgrd会：
- 检查同区域节点对原主节点的可见性
- 若多数节点不可见则取消故障转移
- 记录分区事件到
repmgr.events表
监控告警与性能优化
关键监控指标
| 指标名称 | 正常范围 | 告警阈值 | 监控SQL |
|---|---|---|---|
| 复制延迟(字节) | <1MB | >10MB | SELECT pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn) FROM pg_stat_replication; |
| 跟随状态 | streaming | not streaming | SELECT application_name, state FROM pg_stat_replication; |
| repmgrd进程状态 | running | stopped | SELECT pid, status FROM pg_stat_activity WHERE application_name='repmgrd'; |
性能优化配置
# replication优化
use_replication_slots=yes
replication_type='physical'
# 网络优化
ssh_options='-q -o ConnectTimeout=5 -o TCPKeepAlive=yes'
pg_basebackup_options='--checkpoint=fast'
# 日志优化
log_level='NOTICE'
log_file='/var/log/repmgr/repmgr.log'
log_status_interval=300
故障排除：90%用户会遇到的5个问题
问题1：跟随操作提示"timeline divergence"
ERROR: this node cannot attach to follow target node "node2" (ID 2)
DETAIL: follow target server's timeline 2 forked off current database system timeline 1 before current recovery point 0/6108880
原因：备用节点与新主节点的时间线分歧，通常因为原主节点故障后有数据写入。
解决方法：
# 方法1：使用pg_rewind同步(推荐)
repmgr node rejoin --force-rewind --upstream-node-id=2
# 方法2：重新克隆(数据量大时不推荐)
repmgr standby clone -h node2 -U repmgr -d repmgr --force
问题2：repmgrd未自动触发follow操作
检查步骤：
- 验证repmgrd状态：
systemctl status repmgrd - 检查配置：
grep follow_command /etc/repmgr.conf - 查看日志：
grep "follow_command" /var/log/repmgr/repmgrd.log
常见原因：
follow_command路径错误，必须使用绝对路径- repmgrd没有权限执行命令，需配置sudo免密
promote_command执行失败导致follow未触发
问题3：执行follow后 replication lag持续增长
排查流程：
- 检查网络带宽：
iftop -i eth0 - 验证新主节点性能：
top -b -n 1 | grep postgres - 查看WAL生成速率：
psql -c "SELECT pg_current_wal_lsn();" -x
优化方案：
- 增加WAL发送进程：
max_wal_senders=10 - 启用WAL压缩：
wal_compression=on - 调整checkpoint：
checkpoint_completion_target=0.9
最佳实践：生产环境部署清单
事前准备清单
- 所有节点配置ntpd时间同步
- 建立repmgr用户免密SSH互信
- 配置防火墙允许PostgreSQL(5432)和SSH(22)端口
- 验证
pg_basebackup可正常执行 - 设置
archive_mode=on和WAL归档
操作流程清单
- 执行
repmgr standby follow --dry-run验证 - 记录当前集群状态：
repmgr cluster show > cluster_state_$(date +%F).log - 执行正式跟随命令并记录输出
- 验证集群状态至少5分钟
- 检查应用连接是否自动重定向
事后验证清单
-
repmgr cluster show显示所有节点正常 -
pg_stat_replication显示streaming状态 - 执行写入测试并验证数据同步
- 检查repmgrd日志无错误
- 确认监控告警恢复正常
总结与展望
repmgr的standby follow功能通过自动化元数据同步、配置更新和服务重载，将传统需要30分钟的主从切换操作缩短至3分钟内，大幅降低了PostgreSQL集群的故障恢复时间。结合repmgrd的自动故障转移能力，可以构建真正意义上的高可用PostgreSQL集群。
未来版本中，repmgr计划引入：
- 基于Raft协议的分布式共识机制
- 跨区域同步的智能选主策略
- 与Kubernetes的原生集成
掌握备用节点跟随操作，是PostgreSQL DBA的核心技能之一。建议定期进行故障转移演练，确保在真正故障发生时能够快速响应。收藏本文，下次遇到主从切换问题时即可快速查阅解决方案。
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
