配置PGPool与PostgreSQL负载均衡复制时节点状态异常求助

嘿，我来帮你捋捋这个问题的排查方向——你遇到的是PGPool误判PostgreSQL节点宕机，但实际PostgreSQL服务显示正常的情况，咱们一步步来定位：

我在配置PostgreSQL与PGPool实现负载均衡和复制时，碰到了PGPool节点状态异常的提示：

对应的错误信息为：

The node is in operation. There is connection. postgres: Down

但实际检查PostgreSQL服务状态时，它确实处于运行状态：

root@n43sl:/var/www# service postgresql status
●postgresql.service - PostgreSQL RDBMS
Loaded: loaded (/lib/systemd/system/postgresql.service; enabled; vendor preset: enabled)
Active: active (exited) since Wed 2018-05-09 15:42:33 WIB; 23min ago
Process: 16192 ExecStart=/bin/true (code=exited, status=0/SUCCESS)
Main PID: 16192 (code=exited, status=0/SUCCESS)
Tasks: 0 (limit: 4915)
Memory: 0B
CPU: 0
CGroup: /system.slice/postgresql.service

我的PGPool Admin后端配置如下：

• 先验证PGPool到PostgreSQL的基础连接
  直接在PGPool所在机器上手动测试连接：执行psql -h <你的PostgreSQL_IP> -U <PGPool配置里的用户名> -d <目标数据库>，如果连接失败，会给出具体的错误原因（比如认证失败、端口不通），这是最直接的排查方式。
• 检查PostgreSQL的监听配置
  虽然systemd显示服务active，但PostgreSQL可能没监听正确的IP。执行ss -tulpn | grep postgres，确认它在监听0.0.0.0（允许所有IP访问）或者PGPool所在机器的IP，而不是只监听127.0.0.1（只能本地访问）。如果监听地址不对，修改postgresql.conf里的listen_addresses参数后重启PostgreSQL。
• 核对PGPool的节点配置
  打开PGPool的主配置文件pgpool.conf，检查backend_hostname0、backend_port0是否和PostgreSQL的实际IP、端口完全匹配；同时确认backend_flag0设置为ALLOW_TO_FAILOVER（符合常规场景的配置），错误的标记可能导致状态检测异常。
• 检查PostgreSQL的访问控制规则
  查看PostgreSQL的pg_hba.conf文件，确认是否允许PGPool所在机器的IP地址，以配置的认证方式（比如md5、trust）连接到目标数据库。如果没有对应的规则，添加后需要重新加载PostgreSQL配置（service postgresql reload）。
• 查看PGPool的详细日志
  PGPool的日志文件（默认路径通常是/var/log/pgpool/pgpool.log）里会记录节点检测的详细过程，比如连接超时、认证失败等具体原因，这是定位问题的核心依据，一定要去查看。
• 排查网络与防火墙
  测试PGPool机器和PostgreSQL机器之间的网络连通性：用ping <PostgreSQL_IP>确认网络可达，再用nc -zv <PostgreSQL_IP> 5432测试5432端口是否开放，确保防火墙（包括系统防火墙和云厂商的安全组）没有拦截这个端口的流量。
• 确认PostgreSQL进程是否真的在运行
  systemd显示active (exited)有点奇怪，这说明主服务脚本执行完成，但实际的PostgreSQL数据库进程可能没启动。执行ps aux | grep postgres，查看是否有postgres的守护进程和子进程，如果没有，去查看PostgreSQL自身的日志（比如/var/log/postgresql/postgresql-<版本号>-main.log）排查启动失败原因。

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