PostgreSQL原生的流复制功能虽然稳定，但只靠手工方式管理主从节点，一旦主库故障就需要人工介入切换，业务的连续性很难保障。repmgr正是为了解决这个问题而生的开源工具，它通过一个后台守护进程repmgrd持续监控集群各节点的复制状态，配合replication slot、witness节点等功能，可以做到故障自动切换。本文以两节点主从架构为例，完整走一遍repmgr的安装与集群配置流程。
一、安装前的环境准备与软件安装
本次演示使用两台CentOS服务器，主机名分别为node1（192.168.10.11）和node2（192.168.10.12），均提前安装好PostgreSQL 14。两台机器的/etc/hosts中要互相添加主机名解析，这是repmgr节点间通信的基础，很多新手配置失败就是卡在主机名解析这一步。
安装repmgr推荐使用EDB提供的yum源，命令如下：
# 安装EDB的repo包 yum install -y https://download.postgresql.org/pub/repos/yum/reporpms/EL-7-x86_64/pgdg-redhat-repo-latest.noarch.rpm # 安装与PostgreSQL大版本匹配的repmgr yum install -y repmgr14
安装完成后，可以在/usr/pgsql-14/bin目录下找到repmgr和repmgrd两个可执行文件。建议把这个目录加入PATH环境变量，或者直接在postgres用户的.bash_profile中添加： export PATH=/usr/pgsql-14/bin:$PATH，避免每次都要敲完整路径。
接下来在两台机器上分别创建repmgr专用的元数据库和用户。repmgr需要一个超级用户和一个数据库来存放集群元数据，官方推荐做法是：
-- 使用postgres超级用户登录psql执行 CREATE USER repmgr WITH REPLICATION PASSWORD 'repmgr123'; CREATE DATABASE repmgr OWNER repmgr;
二、核心配置文件调整：pg_hba.conf与postgresql.conf
流复制要正常工作，必须允许repmgr用户从对端节点连接。编辑主库的pg_hba.conf，在文件开头追加两条规则，一条放行普通连接，一条放行复制连接：
host repmgr repmgr 192.168.10.0/24 trust host replication repmgr 192.168.10.0/24 trust
注意replication连接的数据库字段必须写replication而不是具体库名，这是流复制的固定要求。生产环境建议把trust换成scram-sha-256密码认证，并配合.pgpass文件免交互输入密码。
postgresql.conf中有几个关键参数需要调整，主库和备库都建议统一设置：
listen_addresses = '*' max_wal_senders = 10 max_replication_slots = 10 wal_level = 'replica' hot_standby = on archive_mode = on archive_command = 'test ! -f /archive/%f && cp %p /archive/%f'
wal_level设为replica是流复制的最低要求；max_wal_senders决定了可以有几个备库同时拉取WAL，预留一些余量；hot_standby设为on后备库可以开放只读查询。改完配置记得重启数据库生效。另外建议开启检查点相关参数的合理值，比如checkpoint_timeout设为15min，减少频繁checkpoint带来的IO压力。
三、编写repmgr.conf并注册主备节点
repmgr自身的配置文件通常放在数据库的数据目录之外，比如/etc/repmgr/14/repmgr.conf。node1（主库）的配置如下：
node_id = 1 node_name = 'node1' conninfo = 'host=192.168.10.11 user=repmgr dbname=repmgr connect_timeout=2' data_directory = '/var/lib/pgsql/14/data' failover = 'automatic' promote_command = 'repmgr standby promote -f /etc/repmgr/14/repmgr.conf --log-to-file' follow_command = 'repmgr standby follow -f /etc/repmgr/14/repmgr.conf --log-to-file' log_file = '/var/log/repmgr/repmgr.log' reconnect_attempts = 3 reconnect_interval = 5
node2的配置只有node_id和node_name、conninfo中的host不同，其余保持一致。node_id必须在集群内唯一，这是repmgr识别节点的核心标识。
先在主库node1上执行注册：
# 检查配置是否正确 repmgr -f /etc/repmgr/14/repmgr.conf check primary # 注册主节点 repmgr -f /etc/repmgr/14/repmgr.conf primary register
然后在node2上执行克隆。克隆命令会通过pg_basebackup从主库拉取一份完整的基础备份，数据量大的话耗时较长，可以提前估算：
# 先停掉node2上的PostgreSQL systemctl stop postgresql-14 # 克隆主库数据 repmgr -h 192.168.10.11 -U repmgr -d repmgr -f /etc/repmgr/14/repmgr.conf standby clone # 启动备库并注册 systemctl start postgresql-14 repmgr -f /etc/repmgr/14/repmgr.conf standby register
克隆完成后，node2的数据目录中会自动生成standby.signal文件和postgresql.auto.conf中的primary_conninfo配置，这就是备库的身份凭证。最后用repmgr cluster show命令验证，两个节点都显示running状态才算成功。
四、启动repmgrd与切换演练
前面只是搭建了复制关系，要实现自动故障转移还必须启动repmgrd守护进程。修改repmgr.conf确认failover设置为automatic，然后在两个节点分别执行：
# 以postgres用户启动守护进程 repmgrd -f /etc/repmgr/14/repmgr.conf # 用systemd管理的话 systemctl start repmgr14 systemctl enable repmgr14
启动后可以在日志中看到monitoring connection to primary server字样，说明守护进程已在持续探测主库状态。此时可以直接做一次切换演练验证集群可用性：在node2上执行repmgr standby switchover，node1会先降级为备库，node2提升为新主库，整个过程通常在几秒内完成，业务端配合VIP或连接池即可实现接近无感的切换。
常见问题方面，如果standby clone报错connection refused，优先排查pg_hba.conf和防火墙；如果集群 show中显示unreachable，检查各节点conninfo里的主机地址是否写成了localhost；如果repmgrd无法启动，多数是promote_command或follow_command的路径写错导致。把日志级别调到DEBUG2，绝大部分问题都能在日志里找到线索。掌握这套流程后，再扩展witness节点或搭配Keepalived做VIP漂移，就能构建更完善的高可用方案。
repmgr安装流复制PostgreSQL高可用修改时间：2026-09-09 07:54:33