repmgr重加入PostgreSQL节点失败：pg_rewind获取pg_control权限遭拒

问题分析 #

1. 运行中执行repmgr node rejoin报错：rejoin操作要求节点处于离线状态以避免数据冲突，因此必须停止PostgreSQL服务后再执行。
2. 停止服务后pg_rewind执行失败：核心原因是新主节点上的repmgr用户缺少pg_read_binary_file函数的执行权限，PostgreSQL 15默认收紧了这类系统函数的权限控制。

解决方案步骤 #

1. 修复新主节点的权限问题 #

登录新主节点的PostgreSQL，执行以下SQL为repmgr用户授权：

GRANT EXECUTE ON FUNCTION pg_catalog.pg_read_binary_file(text) TO repmgr;
GRANT EXECUTE ON FUNCTION pg_catalog.pg_read_binary_file(text, bigint, bigint, boolean) TO repmgr;

注：如果你的repmgr用户名不是repmgr，替换为实际集群使用的用户名。

2. 停止原故障主节点的PostgreSQL服务 #

以systemd管理的服务为例，执行：

sudo systemctl stop postgresql-15

其他环境可使用对应命令，比如pg_ctl stop -D /var/lib/postgresql/15/main

3. 清理原主节点的集群状态记录（可选） #

在新主节点上执行，强制注销原主节点的旧状态：

repmgr node unregister --node-id <原主节点ID> --force

4. 执行rejoin操作（在原主节点上执行） #

指定新主节点的连接信息，执行重新加入命令：

repmgr node rejoin -d 'host=<新主节点IP> port=5432 user=repmgr dbname=repmgr' --force

连接串需与集群repmgr配置一致，确保repmgr用户能正常访问新主节点。

5. 启动原主节点的PostgreSQL服务 #

sudo systemctl start postgresql-15

6. 验证集群状态 #

在任意节点执行，确认原主节点已作为备节点正常加入：

repmgr cluster show

额外注意事项 #

• PostgreSQL 15对系统函数权限控制更严格，部署repmgr集群时，建议提前为repmgr用户授予必要的系统函数权限，避免故障转移后出现权限问题。
• 如果pg_rewind仍失败，可考虑使用repmgr standby clone重新克隆新主节点数据（会覆盖原节点数据，需谨慎操作）：

  repmgr standby clone -d 'host=<新主节点IP> port=5432 user=repmgr dbname=repmgr' --force
  

内容的提问来源于stack exchange，提问作者Xonos