Azure环境下Hikari 5.1.0连接丢失问题排查咨询

ENV1 配置与问题 #

我们有server.jar和client.jar两个应用，均使用Hikari 5.1.0连接同一Azure SQL Server数据库：

• server.jar部署在两台机器上，通过Hazelcast 5.3.8互联并持续运行
• client.jar作为Hazelcast客户端，仅在用户查询数据库等场景下按需启动
• 数据库支持最大300个连接，原配置每台server分配150个连接，现已调整为每台120个（总计240），预留60个给client.jar

ENV1偶尔出现连接全部丢失的情况，错误日志如下：

2025-03-13 01:03:14.921 [pool-3-thread-1] ERROR - java.sql.SQLTransientConnectionException: HikariPool-1 - Connection is not available, request timed out after 30069ms (total=0, active=0, idle=0, waiting=0)

问题1：调整连接数分配是否有助于解决该问题？

ENV2 配置与问题 #

ENV2几乎不使用client.jar，原本仅偶尔出现相同错误且两分钟后可恢复，但目前出现连接全部丢失且无法恢复的情况，错误日志：

2025-03-18 02:44:46.043 [qtp718505350-94] ERROR  - java.sql.SQLTransientConnectionException: HikariPool-1 - Connection is not available, request timed out after 30004ms (total=0, active=0, idle=0, waiting=0)

已知Azure基础设施在SQL Database服务负载较高时会动态重配置服务器，可能导致客户端连接丢失。

问题2：该Azure动态重配置是否是ENV1连接丢失的原因？为何原ENV2表现不同？

补充说明 #

• ENV1设置了socketTimeout=30000以加快Hikari恢复速度，ENV2未设置该参数
• Azure外的开发环境使用相同SQL Server数据库未出现此问题

Hikari配置参数更新 #

（注：maximumPoolSize=1000为实验配置，常规值为120）

com.zaxxer.hikari.HikariConfig - HikariPool-1 - configuration:
com.zaxxer.hikari.HikariConfig - allowPoolSuspension.............false
com.zaxxer.hikari.HikariConfig - autoCommit......................false
com.zaxxer.hikari.HikariConfig - catalog.........................none
com.zaxxer.hikari.HikariConfig - connectionInitSql...............none
com.zaxxer.hikari.HikariConfig - connectionTestQuery.............none
com.zaxxer.hikari.HikariConfig - connectionTimeout...............30000
com.zaxxer.hikari.HikariConfig - credentials.....................com.zaxxer.hikari.util.Credentials@1d8bd0de
com.zaxxer.hikari.HikariConfig - dataSource......................SQLServerDataSource:1
com.zaxxer.hikari.HikariConfig - dataSourceClassName.............none
com.zaxxer.hikari.HikariConfig - dataSourceJNDI..................none
com.zaxxer.hikari.HikariConfig - dataSourceProperties............{password=<masked>}
com.zaxxer.hikari.HikariConfig - driverClassName.................none
com.zaxxer.hikari.HikariConfig - exceptionOverride...............none
com.zaxxer.hikari.HikariConfig - exceptionOverrideClassName......none
com.zaxxer.hikari.HikariConfig - healthCheckProperties...........{}
com.zaxxer.hikari.HikariConfig - healthCheckRegistry.............none
com.zaxxer.hikari.HikariConfig - idleTimeout.....................600000
com.zaxxer.hikari.HikariConfig - initializationFailTimeout.......1
com.zaxxer.hikari.HikariConfig - isolateInternalQueries..........false
com.zaxxer.hikari.HikariConfig - jdbcUrl.........................none
com.zaxxer.hikari.HikariConfig - keepaliveTime...................30000
com.zaxxer.hikari.HikariConfig - leakDetectionThreshold..........0
com.zaxxer.hikari.HikariConfig - maxLifetime.....................300000
com.zaxxer.hikari.HikariConfig - maximumPoolSize.................1000
com.zaxxer.hikari.HikariConfig - metricRegistry..................none
com.zaxxer.hikari.HikariConfig - metricsTrackerFactory...........none
com.zaxxer.hikari.HikariConfig - minimumIdle.....................1000
com.zaxxer.hikari.HikariConfig - password........................<masked>
com.zaxxer.hikari.HikariConfig - poolName........................"HikariPool-1"
com.zaxxer.hikari.HikariConfig - readOnly........................false
com.zaxxer.hikari.HikariConfig - registerMbeans..................false
com.zaxxer.hikari.HikariConfig - scheduledExecutor...............none
com.zaxxer.hikari.HikariConfig - schema..........................none
com.zaxxer.hikari.HikariConfig - threadFactory...................internal
com.zaxxer.hikari.HikariConfig - transactionIsolation............default
com.zaxxer.hikari.HikariConfig - username........................none
com.zaxxer.hikari.HikariConfig - validationTimeout...............10000

问题1：调整连接数分配是否有助于解决该问题？ #

调整连接数分配无法直接解决连接全部丢失的问题。

从错误日志的连接池状态total=0, active=0, idle=0, waiting=0来看，这不是连接被业务占满的情况（若占满waiting会大于0），而是Hikari连接池已完全空，无法从数据库获取新连接，或所有现有连接被数据库端强制关闭后，Hikari无法重建连接。

不过调整连接数能避免client.jar请求时因连接耗尽报错，但对当前核心的“连接全部丢失”问题无直接修复作用。

问题2：Azure动态重配置是否是ENV1连接丢失的原因？为何原ENV2表现不同？ #

ENV1连接丢失的原因 #

Azure SQL的动态重配置（如负载均衡、故障转移）是ENV1连接丢失的高度可能原因：

• 动态重配置会强制关闭现有数据库连接，导致Hikari池中的连接全部失效
• 错误日志中连接池完全为空、请求超时的状态，符合Hikari在批量连接失效后，尝试重建连接但超时的表现（超时时间与connectionTimeout=30000匹配）

ENV2表现不同的原因 #

ENV2原本能自动恢复、现在无法恢复，结合配置与环境差异分析：

1. socketTimeout配置差异：
   • ENV1设置了socketTimeout=30000，连接因重配置失效时，Hikari能快速检测到异常并触发重建
   • ENV2未设置该参数，JDBC驱动可能持续等待数据库响应，导致Hikari无法及时清理无效连接；原本能恢复是因为重配置频率低，驱动最终检测到连接失效并重建，现在重配置频率上升或其他因素导致重建流程无法完成
2. 连接池配置影响：
   • 实验配置中minimumIdle=1000与maximumPoolSize=1000的极端值，若ENV2曾使用类似配置，会导致连接池重建时压力过大，无法快速恢复；而ENV1常规配置为120，重建压力更小但仍会出现丢失
3. 负载变化：
   • ENV2原本负载低，重配置频率低，现在负载上升导致重配置更频繁，超出了ENV2的自动恢复能力

额外建议 #

• 启用Hikari的connectionTestQuery（如SELECT 1），让Hikari在借出连接前验证有效性，避免无效连接进入业务流程
• 确认maxLifetime（当前为5分钟）小于Azure SQL的默认连接超时（30分钟），确保Hikari主动淘汰旧连接，减少无效连接积累
• 查看Azure监控日志，验证重配置事件是否与连接丢失时间点完全对应

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