中小规模选repmgr，中大型生产环境选patroni+etcd；repmgr报pg_config错误需确保postgres用户下path含pg_config路径并显式指定；patroni卡在waiting需检查etcd健康、postgresql流复制参数及pg_hba认证规则。
repmgr 和 patroni 是目前 Linux 下最主流的两种 PostgreSQL 高可用方案，选哪个取决于你对运维控制粒度、依赖组件和自动化程度的要求。直接说结论：中小规模、希望轻量可控，用 repmgr；中大型生产环境、追求自动故障闭环和强一致性，用 patroni + etcd。
repmgr 安装失败常见报错：configure: error: could not find pg_config
这不是 repmgr 本身的问题，而是它找不到 PostgreSQL 的构建工具链。关键点在于：pg_config 必须在 $PATH 中，且执行用户（通常是 postgres）要有读取权限。
- 先确认 PostgreSQL 是否已安装并可执行：
which pg_config，如果返回空，说明没装或没加到 PATH - 如果是源码安装的 PostgreSQL，
pg_config默认在$PGHOME/bin/下，比如/opt/module/pgsql16/pgsql/bin/pg_config - 编译
repmgr时必须显式指定路径：./configure PG_CONFIG=/opt/module/pgsql16/pgsql/bin/pg_config - 别在 root 下跑
./configure，切到postgres用户再执行，否则即使路径对，也可能因权限拒绝访问pg_config或相关头文件
patroni 启动后一直卡在 waiting for primary to become healthy
这是 Patroni 没法连上主库的表现，不是 Patroni 自身故障，而是底层连接或认证断了。重点排查三处：
-
etcd是否健康：在任意节点执行etcdctl cluster-health，返回cluster is healthy才算通；如果报context deadline exceeded，说明 Patroni 配置里的etcd.host地址或端口不对，或防火墙拦了 2379 -
postgresql.conf中是否漏配：wal_level = replica、max_wal_senders = 10、hot_standby = on—— 缺一不可，且改完要重启 PostgreSQL -
pg_hba.conf是否允许 Patroni 用户双向访问：主备节点都要有两条规则：host replication patroni 10.197.166.7/32 scram-sha-256和host all patroni 10.197.166.7/32 scram-sha-256，IP 换成实际节点地址
repmgr 注册节点时报 ERROR: connection to database failed
这个错误表面是连不上数据库，但根源往往不在网络，而在 repmgr 用户权限或连接参数配置错位。
- 确保主库上已创建
repmgr数据库和用户：CREATE DATABASE repmgr OWNER repmgr;，且该用户有SUPERUSER权限（repmgrv5+ 要求） -
repmgr.conf里conninfo的host必须写成 IP，不能写localhost或主机名——因为从备库发起注册时，localhost指的是它自己，不是主库 - 检查
pg_hba.conf是否只放行了127.0.0.1，而没放开集群内网段，例如：host repmgr repmgr 10.197.167.0/24 scram-sha-256 - 如果用了
scram-sha-256认证，密码必须用psql -U repmgr -d repmgr -c "ALTER USER repmgr PASSWORD 'xxx';"重设，明文密码不生效
真正容易被忽略的是：所有高可用组件（repmgr、patroni、etcd）都依赖稳定的底层流复制链路。只要 pg_stat_replication 在主库查不到备库记录，上面任何高可用工具都只是空转。先让 psql -h 备库IP -c "SELECT 1" 能连上、pg_basebackup 能拉下基础备份，再谈高可用。
