Quarkus反应式MySQL客户端偶发ClosedConnectionException排查咨询

针对你使用Quarkus 3.5.1 + quarkus-reactive-mysql-client（Vertx MySQL Client 4.4.6）连接Aurora MySQL 8.0只读副本时遇到的偶发连接断开问题，以下是具体的影响因素分析：

• Aurora只读副本的服务器端断开机制

  • Aurora只读副本可能因后台维护（如实例补丁、故障切换、自动缩放）主动断开连接，这类操作属于AWS后台行为，无提前通知，客户端复用连接时就会触发该错误。
  • 检查Aurora的wait_timeout和interactive_timeout参数，若这两个值小于客户端配置的idle-timeout，服务器会先于客户端回收空闲连接，而连接池仍认为连接有效，复用时报错。即使你调整了客户端idle-timeout，也需确保该值小于等于服务器的超时参数，避免服务器主动断开未被客户端回收的连接。

• Vertx MySQL Client连接池配置疏漏

  • 仅调整idle-timeout不够，需检查max-lifetime参数：若连接存活时长超过该值未被回收，服务器端可能已断开连接，复用即报错。建议设置合理的max-lifetime（比如比Aurora的wait_timeout小30秒）。
  • 未启用连接有效性验证：可配置connect-attempts参数，或在获取连接时执行SELECT 1这类轻量查询验证连接状态，避免复用失效连接。同时确认pool-reconnect-attempts和pool-reconnect-interval是否开启自动重连机制，确保连接池能主动替换失效连接。
  • Vertx MySQL Client 4.4.6的已知问题：该版本可能存在连接存活检测的bug，导致无法及时识别已断开的连接。可查阅该版本的release notes，确认是否有相关修复，必要时升级到更高稳定版本。

• 网络中间件的超时拦截

  • 检查AWS负载均衡器（如NLB/ALB）、防火墙或代理的空闲超时设置：若这些中间件的超时时间短于客户端和服务器的超时值，会主动断开TCP连接，客户端无感知，复用连接时触发错误。需确保中间件的超时时间大于等于客户端的idle-timeout。
  • 偶发网络波动、丢包：TCP连接在底层被意外断开，客户端未及时触发检测，后续使用连接时就会出现“未读取到服务器响应”的错误。

• Quarkus Reactive上下文的连接管理问题

  • 连接泄漏：在异步操作中未正确将连接归还到池，导致连接长时间闲置被服务器断开，后续复用时报错。需检查代码中是否存在未释放连接的场景（如异常分支未正确关闭连接）。
  • 配置冲突：Quarkus的quarkus.datasource.reactive.*配置与Vertx原生配置是否存在覆盖冲突，比如quarkus.datasource.reactive.idle-timeout是否真正生效，可通过日志确认连接池的实际参数配置。

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