通过pgbouncer连接PostgreSQL只读副本时出现间歇性连接失败求助

问题背景 #

在Open Telecom Cloud部署PostgreSQL 12.16只读副本时，遇到间歇性连接异常：通过K8s集群内的pgbouncer连接只读副本时，频繁抛出以下错误：

[suite-app] datetime[error] [exception.CDbException] SQLSTATE[HY000]: General error: 7 server closed the connection unexpectedly
[suite-app] This probably means the server terminated abnormally
[suite-app] before or while processing the request.

但直接连接只读副本、或pgbouncer连接主实例均正常，仅pgbouncer+只读副本的组合出现问题。已尝试新版pgbouncer、单独部署只读专用旧版pgbouncer，问题依旧。当前配置：单台带静态IP的只读副本（配置入pgbouncer），副本与主实例配置、CPU/内存规格完全一致。

一、优先收集的排查数据 #

• 抓取pgbouncer日志，重点定位应用报错时间段的连接异常：

  kubectl logs <pgbouncer-pod-name> --since=1h | grep -E 'server_closed|conn_failed|error'
  

  关注是否有server_closed、conn_failed等关键字段，判断是pgbouncer主动断开还是副本端触发断连。
• 提取只读副本的PostgreSQL日志，检查报错时段内的FATAL、PANIC级日志，以及connection terminated、wal同步相关的异常信息，确认副本是否有进程崩溃、复制中断等情况。
• 核对pgbouncer核心配置参数：
  • server_idle_timeout/server_lifetime：是否设置过短，导致副本端连接被主动回收？
  • pool_mode：当前是会话池、事务池还是语句池？事务/语句池的连接复用可能触发副本端的只读状态限制。
  • server_check_interval：是否开启了后端连接健康检测，检测间隔是否合理？
• 检查K8s网络监控：查看pgbouncer到只读副本之间的网络是否有间歇性丢包、延迟突增，或TCP连接被重置（RST包）的情况。

二、针对性排查方向 #

1. 只读副本的连接回收与资源限制 #

• 确认副本的max_connections、max_wal_senders配置：是否因为流复制连接占用过多资源，导致pgbouncer的新连接被拒绝？
• 对比主实例与副本的idle_in_transaction_session_timeout、tcp_keepalives_idle/tcp_keepalives_interval参数：是否副本端的连接超时设置更严格，导致空闲连接被主动断开，而pgbouncer未及时感知？

2. pgbouncer与副本的协议兼容性 #

• 检查pgbouncer的ignore_startup_parameters配置：是否包含只读副本特有的参数（如hot_standby），导致连接初始化时出现协议不兼容？
• 开启pgbouncer的log_connections、log_disconnections选项，详细记录连接建立/断开的全流程，对比主实例与副本的连接日志差异，定位异常节点。

3. 云平台特性限制 #

• 排查Open Telecom Cloud对只读副本的特殊限制：是否有流量阈值、连接数上限，或副本在同步wal时的资源波动导致临时无法响应连接？
• 确认K8s NetworkPolicy配置：是否允许pgbouncer所在命名空间访问只读副本的静态IP，是否存在间歇性的规则生效异常？

三、临时缓解方案 #

• 调整pgbouncer的server_check_interval为30秒左右，让pgbouncer定期检测后端连接可用性，及时剔除失效连接。
• 开启pgbouncer的server_reset_query，设置为DISCARD ALL;，确保每次复用连接时重置会话状态，避免只读副本的会话残留问题。

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