PostgreSQL流复制虽然能实现数据冗余，但原生并不提供故障检测和自动提升。需要外部工具介入。repmgr作为PostgreSQL生态中成熟的复制管理与自动故障切换工具，可以帮助数据库管理员在主机故障时自动将备库提升为主库，并重新调整复制拓扑。其设计目标包括减少恢复时间、降低人为操作风险，以及提供清晰的节点状态视图。以下将围绕安装、配置、切换流程和常见问题展开。
一、repmgr的组成与故障检测原理
repmgr由命令行工具和repmgrd守护进程组成。命令行负责注册、克隆、提升等管理操作；repmgrd常驻每个节点，周期性地连接本地PostgreSQL，确认实例健康，并尝试通过复制连接探测上游主库。元数据保存在repmgr schema中，例如repmgr.nodes表记录节点信息、类型、优先级、连接字符串等。当备库上的repmgrd发现主库连接失败次数超过阈值，会进入候选主库评估流程。
评估过程依赖repmgr.conf中的priority、location等参数。priority数值越低优先级越高。location用于同城或异地标识，默认情况下repmgrd只会在相同location内选择新主，除非设置promote_behavior参数。为了避免孤立节点误判，可以配置见证服务器（witness server），它是一个不承载数据的轻量实例，只参与见证和投票。如果主库与备库之间网络分区，见证服务器可以帮助多数派判断哪一侧应该继续服务，降低脑裂概率。
一旦确定本节点为提升对象，repmgrd会调用promote_command，通常是repmgr standby promote。提升完成后，事件通知通过event_notification_command触发，可调用脚本发送告警或更新连接池。其他备库收到新主信息后，通过follow_command重新指向新主。整个流程无需人工干预，但建议保留通知渠道以便及时介入。
二、安装repmgr与初始化流复制集群
以Debian或Ubuntu为例，可以通过2ndQuadrant仓库安装repmgr，RHEL或CentOS也提供rpm包。源码安装需要先安装PostgreSQL开发包，然后执行make install。安装后，要在每个节点配置repmgr.conf，至少包含节点ID、节点名称、连接串、数据目录和复制用户等。示例如下：node_id=1、node_name=pg1、conninfo=host=192.168.10.11 user=repmgr dbname=repmgr。
在PostgreSQL侧需要准备复制用户并允许远程连接，建议使用具备replication和登录权限的专用用户。同时调整postgresql.conf中的参数：wal_level=replica、max_wal_senders=10、hot_standby=on、archive_mode=on等。pg_hba.conf需要放行复制连接。下面是一段配置示例：
wal_level = replica max_wal_senders = 10 max_replication_slots = 10 hot_standby = on archive_mode = on archive_command = 'test ! -f /var/lib/postgresql/archive/%f && cp %p /var/lib/postgresql/archive/%f'
主节点执行repmgr primary register完成注册。备节点可以使用repmgr standby clone -h 主库地址从主库做基础备份，然后启动PostgreSQL并执行repmgr standby register完成注册。克隆过程会调用pg_basebackup，需要确保主备大版本一致。验证集群状态可通过repmgr cluster show查看各节点角色和连接情况。
三、配置自动故障切换的关键参数
自动切换的核心是repmgrd配置文件或repmgr.conf中的failover=automatic。该参数必须显式设置，否则默认为手动模式。另外monitor_interval_secs控制探测间隔，一般为2到5秒；reconnect_attempts和reconnect_interval决定判定主库失联前的重试次数和间隔。合理设置这些参数可以避免网络抖动导致误切换。
下面是一个完整的repmgr.conf示例，包含自动切换相关参数：
node_id=1 node_name=pg1 conninfo=host=192.168.10.11 user=repmgr dbname=repmgr data_directory=/var/lib/postgresql/14/main failover=automatic promote_command=repmgr standby promote -f /etc/repmgr/repmgr.conf follow_command=repmgr standby follow -f /etc/repmgr/repmgr.conf monitor_interval_secs=3 reconnect_attempts=3 reconnect_interval=5 priority=100 location=dc1 use_replication_slots=1 event_notification_command=/usr/local/bin/repmgr_notify.sh
提升命令repmgr standby promote会将备库从恢复模式切换为主库，时间线递增。follow命令让其他备库重新连接新主。如果使用虚拟IP或pgBouncer，切换后需要更新路由，可以在event_notification_command脚本中处理。生产环境建议结合VIP漂移，避免应用层连接串硬编码，否则故障切换后应用仍然连接旧地址。
四、避免脑裂与切换后的运维注意事项
自动故障切换最大的风险是脑裂，即网络隔离时两个节点都认为自己是主库。repmgr本身通过候选评估和见证服务器降低概率，但并不能像强一致协议那样完全杜绝。对于要求严格的场景，应配置witness server，并将见证节点独立部署到第三个网络区域。同时关闭不参与选举节点的提升能力，利用priority和location限制候选范围，避免低优先级或异地节点被意外提升。
另一个常见问题是旧主恢复后如何处理。repmgr提供了repmgr node rejoin命令，可将旧主作为备库重新加入集群并追平数据。操作前需要确保旧主没有遗漏未归档的事务，否则需要重新构建。可以通过repmgr node check和repmgr cluster crosscheck检查集群一致性。如果旧主与当前主发生时间线分叉，建议重新克隆而不是强制rejoin，否则可能导致数据不一致。
监控与演练同样重要。repmgr状态可以输出JSON格式，方便对接Nagios、Prometheus等监控系统。每季度至少模拟一次主库宕机，验证自动切换时间是否满足RTO，确认应用连接池能自动刷新拓扑。对于跨机房部署，location分隔和同步复制参数（如synchronous_commit=remote_apply）需要综合考虑，避免同步备库不可用时堵塞主库写入。
与其他方案对比，Patroni基于etcd等分布式共识，脑裂防护更强；pgpool-II更适合读写分离场景。repmgr优势是轻量、与PostgreSQL原生工具链契合、配置简单，适合中小规模集群和希望快速落地的团队。根据业务对RPO和RTO的要求选择即可。
PostgreSQL高可用repmgr自动故障切换修改时间：2026-09-19 14:13:43