incident-db-conn-pool

一次发布引入的连接未释放，如何把“数据库变慢”的误判纠正为应用侧连接池泄漏。

现象

某订单服务发布后约二十分钟，接口 P99 从百毫秒级升到数秒，随后 5xx 快速上升。应用日志开始出现连接池等待超时：

HikariPool-1 - Connection is not available, request timed out after 30000ms.

数据库侧同时出现 FATAL: sorry, too many clients already，与订单服务共用同一实例的其他服务也开始连接失败。奇怪的是，数据库 CPU 只有一成多，磁盘 I/O 和慢查询日志都没有明显变化；应用却是“线程都在、请求不动”。

连接数曲线很有辨识度：发布完成后呈阶梯上升，每一波流量高峰抬高一个台阶，之后从不回落；重启 Pod 会短暂下降，但很快又爬到上限。连接池指标显示 active 长期等于 maximumPoolSize，idle 为 0，等待获取连接的线程持续增加。

时间线

影响面

订单写入失败约三十多分钟，部分请求在客户端重试后成功，少量请求需要人工对账。由于多个服务共用数据库实例，连接被占满后发生了级联失败：即使某个服务自身没有泄漏，也会因为拿不到连接而报错。读接口和后台任务同样受影响，消息队列出现积压。

扩容副本的操作在短时间内让情况更糟，因为每个 Pod 都会建立自己的连接池，副本数增加意味着数据库侧连接总数按倍数增长。事故没有造成数据丢失，但重试流量放大了数据库压力，恢复后还需要检查重复下单和幂等性。

误导线索

最初的判断是“数据库慢导致请求堆积”，因为告警同时出现 P99 上升和连接数上涨，而且 pg_stat_activity 顶部确实有几条运行时间很长的 SQL。团队先调大 max_connections，又准备加索引，但都没有触及问题。

推翻这个判断的证据有三条：

1. 数据库资源与“慢”不匹配。 CPU 只有一成多，磁盘延迟正常，慢查询日志没有新增；如果真是慢 SQL，通常会看到 active 会话占满、CPU 或 I/O 饱和，而不是大量会话空闲。
2. 会话状态是 idle，等待事件是 ClientRead。 这说明数据库已经执行完上一条命令，正在等客户端发送下一条命令。数据库在等应用，不是应用在等数据库。少数 idle in transaction 会话是另一条长事务留下的噪声，不是本次连接耗尽的主因。
3. 扩容副本让连接数按 Pod 数线性增长。 如果是流量导致的连接不足，扩容应该缓解；实际结果是每个新 Pod 都再开一组连接，说明连接没有被归还，池子上限只是被复制了更多份。

决定性证据来自应用侧：连接池 active 等于上限、idle 为 0，线程栈大量阻塞在 HikariPool.getConnection，而数据库端对应会话却是空闲的。再对照发布 diff，发现新接口在异常分支提前返回，连接没有关闭。至此“数据库慢”的假设被完全排除。

根因

直接原因是新版本新增的批量查询接口手工从 DataSource 获取连接，在查询异常或超时分支直接 return，没有在 finally 中关闭 Connection、Statement 和 ResultSet。连接对象离开业务方法后仍被连接池视为“已借出”，数据库会话一直保持 idle，直到进程重启或连接被人工终止。

促成条件有四个：

• 连接池没有开启泄漏检测，leakDetectionThreshold 为 0（未启用），泄漏只能等到耗尽才暴露。
• 每个 Pod 的 maximumPoolSize 设置偏大，而数据库 max_connections 没有按“所有服务副本数 × 池大小 + 管理余量”做预算。扩容时连接总数直接突破上限。
• 上游对连接池超时做了重试，重试请求继续排队获取连接，进一步拉长等待时间，形成正反馈。
• 数据库没有设置 idle_in_transaction_session_timeout，长事务和空闲会话缺少兜底回收；这虽然不是本次主因，但延长了恢复时间。

需要区分“泄漏”和“长事务”：泄漏是连接借出后永远不还，池子 active 打满而数据库会话空闲；长事务是连接仍在事务中（典型状态是 idle in transaction）或长时间 active，数据库端能看到事务尚未结束。两者的止血动作不同，混在一起会误判。

修复

止血顺序是“先停止新增泄漏，再释放已泄漏连接，最后修代码”：

# 1. 回滚到上一个稳定版本
kubectl -n order rollout undo deploy/order-svc
kubectl -n order rollout status deploy/order-svc

# 2. 查看连接池与线程状态（若启用了 actuator）
kubectl -n order exec deploy/order-svc -- \
  curl -s localhost:8080/actuator/metrics/hikaricp.connections.active
kubectl -n order exec deploy/order-svc -- \
  curl -s localhost:8080/actuator/metrics/hikaricp.connections.pending

# 3. 确认 Java 进程为 PID 1 时抓线程栈
kubectl -n order exec deploy/order-svc -- jstack 1 | grep -A 20 'HikariPool'

数据库侧先看状态分布，再决定是否终止会话：

psql -h <db-host> -U monitor -d postgres -c \
  "select state, count(*) from pg_stat_activity group by 1 order by 2 desc;"

psql -h <db-host> -U monitor -d postgres -c \
  "select application_name, client_addr, state, count(*),
          max(now() - state_change) as max_idle
     from pg_stat_activity
    group by 1,2,3 order by 4 desc limit 20;"

psql -h <db-host> -U monitor -d postgres -c \
  "select pid, usename, application_name, state, wait_event_type, wait_event,
          now() - state_change as since
     from pg_stat_activity
    where state <> 'active' order by since desc limit 20;"

只有在确认会话属于该服务、处于 idle 且不在事务中时，才按应用名批量终止，避免误杀其他业务。前提是连接串设置了 application_name；如果没有设置，先用 client_addr 映射到 Pod IP 再判断：

psql -h <db-host> -U monitor -d postgres -c \
  "select pg_terminate_backend(pid)
     from pg_stat_activity
    where application_name = 'order-svc'
      and state = 'idle'
      and state_change < now() - interval '5 minutes';"

MySQL 环境对应的检查方式：

mysql -h <db-host> -u monitor -p -e \
  "show status like 'Threads_connected';
   show variables like 'max_connections';
   select id, user, host, db, command, time, state, info
     from information_schema.processlist
    order by time desc limit 20;"

代码修复要落在资源管理上：用 try-with-resources 或框架托管的事务模板，确保异常路径也关闭连接；禁止在持有连接时调用外部 HTTP、发送消息或做长时间计算；为下游调用设置独立超时，且总预算小于连接池等待时间。

连接池参数按实际负载设置，而不是照抄模板：

• maximumPoolSize 与副本数、数据库连接预算一起计算，HPA 的最大副本数也必须纳入公式。
• connectionTimeout 要短于上游超时，让失败快速暴露。
• leakDetectionThreshold 设为高于正常最长查询的阈值，用于日志告警，不能替代修复。
• maxLifetime 应短于数据库或连接代理的空闲断开时间，避免拿到已被服务端关闭的连接。
• idleTimeout、keepaliveTime 按数据库和网络环境调整。

数据库侧增加保护：为每个服务使用独立账号并设置 CONNECTION LIMIT，设置 statement_timeout 和 idle_in_transaction_session_timeout，让失控连接无法无限占用资源。连接数需求较大的场景可以引入 PgBouncer 做事务级池化，但要注意 session 级特性、预处理语句和 LISTEN/NOTIFY 的兼容性。

预防

• 建立连接预算：所有副本数 × 每 Pod 池大小 + 其他服务 + 管理保留 必须小于数据库上限，并留出故障切换和扩容余量。
• 连接池饱和度、等待线程数、获取连接耗时应进入统一看板；active/max 超过 80% 持续五分钟就告警，不要等报错。
• 把 leakDetectionThreshold 和 statement_timeout 纳入服务模板，在测试环境用故障注入验证异常分支不会泄漏。
• 代码评审增加资源关闭检查，静态扫描 getConnection() 后是否在所有路径关闭；优先使用框架托管连接。
• 压测时注入下游超时和异常，观察连接数是否在流量回落后回到基线；只压正常路径发现不了泄漏。
• 发布采用灰度，先观察一个副本的连接曲线，再扩大范围；扩容前先确认数据库连接预算。
• 为每个服务配置独立数据库账号和连接上限，避免一个服务拖垮整个实例。
• 把“连接数阶梯上升、重启后短暂恢复”写进 runbook，作为连接池泄漏的典型指纹。

相关命令

• postgres-connection-exhausted — PostgreSQL 连接耗尽的定位与恢复
• mysql-too-many-connections — MySQL Too many connections 的处理
• mysql-connection-failed — 数据库连接失败的通用排查
• pgbouncer — 用连接池代理控制后端连接数
• postgresql — PostgreSQL 日常运维与参数
• mysql-router — MySQL 连接路由与高可用

参考链接

• PostgreSQL: Monitoring pg_stat_activity
• PostgreSQL: Connection Settings
• HikariCP Configuration
• PgBouncer Usage
• MySQL: Too many connections

读完自测

合上页面，先回答，再展开对照。

1. 为什么“数据库 CPU 不高 + 会话大量 idle”更像应用连接池泄漏，而不是数据库慢？
2. 扩容应用副本为什么可能让连接耗尽更严重？连接预算应该怎么算？
3. 回滚并重启 Pod 后，还需要做哪些事才能让连接数立即回落并避免复发？