ERROR druid.sql.Statement - {conn-10057, stmt-22478} execute error. select 'x' org.opengauss.util.PSQLException: [192.168.0.199:63161/192.168.0.63:55432] socket is not closed; Sending Urgent packet failed, detail: Connection reset by peer: send. An I/O error occured while sending to the backend.detail:Connection reset by peer: socket write error;

<think>嗯，用户的问题是关于Druid连接池报错"SQL execute error"和OpenGauss数据库的"connection reset by peer"错误组合。从日志看涉及网络层连接中断，这通常比纯应用层错误更棘手。 用户可能正在处理生产环境数据库连接不稳定的问题，特别是升级Druid后出现的异常。ta的日志里同时出现Druid的闲置连接丢弃警告和OpenGauss的TCP连接重置报错，说明问题可能发生在三个层面：连接池配置、网络基础设施、数据库服务端设置。 注意到引用中提到的Druid 1.1.23版本特性很重要——这个版本新增了连接有效性检查机制。当物理连接被数据库或防火墙中断时，Druid会主动废弃这些"僵尸连接"。但用户当前的报错表明这个机制似乎未能完全预防问题。 关于"connection reset by peer"这个TCP层错误，需要重点检查： 1) OpenGauss的max_connections是否过小导致强制断连 2) 云环境或容器网络是否存在会话超时设置（比如阿里云SLB默认60秒空闲断开） 3) 防火墙的TCP keepalive策略是否与数据库不兼容 特别要注意OpenGauss的tcp_keepalives_idle参数默认是2小时，远高于多数云防火墙设置。建议用户将该值调整为300秒左右，并同步调整Druid的maxEvictableIdleTimeMillis低于防火墙超时阈值。 另外从报错细节看，lastPacketReceivedIdleMillis达到124秒，说明应用存在长时间查询空闲。可能需要为复杂查询配置Druid的validationQueryTimeout，或者检查是否有未关闭的ResultSet。 最后建议用户用tcpdump抓包验证RST包来源，这能直接定位是数据库主动断连还是中间设备行为。如果是数据库端问题，还需检查OpenGauss的日志是否有authentication timeout或too many clients报错。</think>## 问题分析：Druid SQL执行错误与OpenGauss连接中断 此错误组合表明**Druid连接池中的物理连接被数据库服务器（OpenGauss）或中间网络设备主动关闭**，导致应用尝试使用该连接执行SQL时失败。核心原因在于TCP连接被重置（`connection reset by peer`），通常与网络不稳定、连接超时或服务器主动断开有关。 ### 关键原因及解决方案 #### 1. **网络连接不稳定或超时** * **表现**：`connection reset by peer`是TCP层错误，表明对端（OpenGauss服务器或中间设备）主动关闭了连接。 * **排查**： * 检查应用服务器与OpenGauss服务器之间的网络状况（延迟、丢包率）。 * 确认防火墙、负载均衡器等中间设备的**TCP空闲超时设置**（如阿里云SLB默认为900秒）。 * **解决方案**： * 调整Druid的**连接保活参数**，确保连接活跃度低于网络设备超时阈值： ```properties # 启用保活探测 (单位：秒) druid.keepAlive=true # 发送保活探测包的空闲时间 (需小于网络设备超时时间) druid.keepAliveBetweenTimeMillis=300000 # 例如5分钟 # 探测失败重试次数 druid.keepAliveQueryCount=3 ``` #### 2. **OpenGauss服务器端配置限制** * **表现**：OpenGauss可能因空闲超时或连接数限制主动断开连接。 * **排查**：检查OpenGauss配置： ```sql -- 查看空闲连接超时设置 (单位：秒) SHOW tcp_keepalives_idle; SHOW tcp_keepalives_interval; SHOW tcp_keepalives_count; -- 查看最大连接数限制 SHOW max_connections; ``` * **解决方案**： * 确保`tcp_keepalives_idle`值小于网络设备超时时间（如设置为300秒）。 * 调整`max_connections`避免因连接耗尽导致拒绝。 #### 3. **Druid连接池配置不当** * **表现**：连接在池中闲置过久被OpenGauss断开后，Druid未及时检测或移除。 * **解决方案**：优化Druid配置： ```properties # 启用空闲连接校验 (推荐用SELECT 1) druid.testWhileIdle=true druid.validationQuery=SELECT 1 # 缩短空闲连接检查周期 (单位：毫秒) druid.timeBetweenEvictionRunsMillis=60000 # 1分钟 # 设置连接最大空闲时间 (需小于数据库/网络超时) druid.minEvictableIdleTimeMillis=300000 # 5分钟 # 升级后关键参数：避免误报长时无接收连接 (1.1.23+) druid.maxEvictableIdleTimeMillis=600000 # 10分钟，需大于minEvictableIdleTimeMillis ``` #### 4. **防火墙或安全策略拦截** * **排查**：检查服务器防火墙、安全组规则是否允许持续的长连接。 * **解决方案**：放行应用服务器与OpenGauss的端口通信，调整会话保持策略。 ### 验证步骤 1. **网络诊断**：使用`telnet`或`nc`测试端口连通性，通过`ping`/`traceroute`检查链路稳定性。 2. **抓包分析**：在应用服务器抓包（`tcpdump`），观察TCP连接是否收到`RST`标志。 3. **日志关联**：对比Druid断开连接的时间点与OpenGauss的`pg_log`，确认服务器端断连原因。 > **关键点**：确保**Druid的最大空闲时间**（`maxEvictableIdleTimeMillis`）始终小于**网络设备超时时间**和**OpenGauss的TCP保活超时**，这是预防`connection reset`的核心[^1]。 --- ###