MySQL-CommunicationsException异常的三个典型场景及解决方法
我们在使用MySQL数据库的时候,偶尔会遇到com.mysql.jdbc.exceptions.jdbc4.CommunicationsException,为了以后能够更快速的定位解决该问题,下面对该异常出现的场景及解决方法进行总结,希望能起到抛砖引玉的作用。
场景一
场景描述
wait_timeout
根因分析
异常的原因是数据库连接空闲时间超过了MySQL服务器配置的wait_timeout,即上图中【2.3 数据库操作】时候的时间 【减去】【1.5 放入连接池中】时候的时间【大于】wait_timeout。
解决办法
方法一
mysql5以前的版本可以直接在jdbcurl的配置中附加上“autoReconnect=true”。
方法二
将mysql的全局变量wait_timeout的值修改为最大。
show global variables like "wait_timeout";
方法三【建议采纳的方案】
目前项目采用的数据库连接池是druid,解决该异常用到的配置项如下:
配置 |
缺省值 |
说明 |
validationQuery |
|
用来检测连接是否有效的sql,要求是一个查询语句,常用select 'x'。如果validationQuery为null,testOnBorrow、testOnReturn、testWhileIdle都不会起作用。 |
testWhileIdle |
false |
建议配置为true,不影响性能,并且保证安全性。申请连接的时候检测,如果空闲时间大于 |
timeBetweenEvictionRunsMillis |
1分钟 |
有两个含义: |
minEvictableIdleTimeMillis |
|
连接保持空闲而不被驱逐的最小时间 |
场景二
场景描述
应用阻塞无响应
根因分析
客户端发送select语句后,服务端往客户端写大量数据,客户端需要等待超过1分钟才能继续写入,服务端就会把这种写入时超过1分钟(默认值)等待的连接直接关闭。
而为什么会超过1分钟?根因是jdbc程序在接收大量数据时会耗费大量的cpu跟内存资源,还需要不断做的GC,导致接收暂停,一旦GC时间超过net_write_timeout,mysql则会关闭连接。
根因
解决办法
方法一
根据业务场景增大net_write_timeout
SET GLOBAL net_write_timeout =180; SELECT @@global.net_write_timeout ; SELECT @@session.net_read_timeout ; show variables like '%timeout%'
方法二【建议采纳的方案】
根据业务场景,优化应用程序。
优化方向:
- 优化SQL,通过分页的方式减少一次查询返回的数据量
- 优化应用,减少应用停顿时间
场景三
场景描述
SSL
问题分析
MySQL server versions like 5.6.25 and earlier or 5.7.5 and earlier,客户端连接属性useSSL默认是false;MySQL server versions like 5.6.25+ or 5.7.5+,客户端连接属性useSSL默认是true。
默认useSSL=true的MySQL server版本,客户端连接属性还需要配置其他额外的连接属性,如果没有配置会抛出CommunicationsException异常。
解决办法
方法一
在不需要SSL连接的场景下,显示设置useSSL=false
方法二
在需要SSL连接的场景下,客户端和服务端都需要进行正确的配置。
具体配置可以参考官网文档:Connecting Securely Using SSL:https://dev.mysql.com/doc/connector-j/8.0/en/connector-j-reference-using-ssl.html
原文地址:https://www.toutiao.com/article/7153480165631197707/
1.本站遵循行业规范,任何转载的稿件都会明确标注作者和来源;2.本站的原创文章,请转载时务必注明文章作者和来源,不尊重原创的行为我们将追究责任;3.作者投稿可能会经我们编辑修改或补充。