mysql 连接异常Communications link failure
mysql 连接异常Communications link failure
前言碎语
最近在监控线上日志时发现，时长会抛出如：com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure The last packet successfully received from the server was 4,977,174 milliseconds ago. The last packet sent successfully to the server was 1 milliseconds ago 异常信息，通常见到如上异常，是因为应用使用了连接池管理连接，有些连接已经失效了，拿失效的连接去请求mysql导致的，这个就是经典的mysql八小时的问题
1.异常抛出时机：
1.连接心跳检测时，此连接已被mysql连接超时策略设置为失效了，所以链接心跳检测失败抛出，此时连接池会剔除心跳失败的连接，此次异常不影响实际业务
2.失效的连接还在连接池里，没有被连接心跳检测到，被应用业务sql拿到了连接，这种情况会影响应用
一般数据库连接池设置的心跳检测时间小于数据库wait_timeout，所以，一般都会被心跳检测去触发剔除，被应用拿到的概率比较小。可见于这种异常对应用影响不大，但异常多了还是不舒服斯基，下面我们了解下相关的知识点，来看看如何解决这个问题
2..首先了解下mysql的超时参数interactive_timeout和wait_timeout
这两个参数都是连接超时失效的，区别如下：
(1)interactive_timeout: 参数含义：服务器关闭交互式连接前等待活动的秒数。交互式客户端定义为在mysql_real_connect()中使用CLIENT_INTERACTIVE选项的客户端。 参数默认值：28800秒（8小时） (2)wait_timeout: 参数含义：服务器关闭非交互连接之前等待活动的秒数。 在线程启动时，根据全局wait_timeout值或全局interactive_timeout值初始化会话wait_timeout值，取决于客户端类型(由mysql_real_connect()的连接选项CLIENT_INTERACTIVE定义)。 参数默认值：28800秒（8小时)
这里作用于我们jdbc应用参数为wait_timeout，mysql实例默认为8个小时，所以，如果没有调整这个参数的话，上面的异常也会有，但是频率不会那么高，不容易发现这个问题。楼主这边的情况是，数据库管理员将这个值设置为30分钟有效。我们连接池允许20个活动链接，所以基本上30分钟都会抛一次这个异常
3..如何解决这个问题？
1.可以调大mysql的实例的wait_timeout参数，set GLOBAL WAIT_TIMEOUT=86400，这种情况可以减少因为连接池没有剔除无效链接信息导致的应用拿到失效链接的问题概率
2.配置连接池testOnBorrow参数为true，这样，每次拿到链接会去校验下是否有效，不会导致应用拿到失败的链接，这种情况如果你的wait_timeout设置的过小，还是会频繁抛出Communications link failure的异常，不过不影响应用，都是心跳触发的，这样能保证应用拿到的都是有效的连接
3.通过配置连接池的testWhileIdle和timeBetweenEvictionRunsMillis，Destroy线程会检测连接的间隔时间，如果连接空闲时间大于等于minEvictableIdleTimeMillis则关闭物理连接,所以timeBetweenEvictionRunsMillis的值稍微小于数据库wait_timeout就好。testWhileIdle设置为true，应用申请连接的时候会有检测，如果空闲时间大于timeBetweenEvictionRunsMillis，执行validationQuery检测连接是否有效
最后附上一张连接池配置参数表供参考（DBCP&Druid）
配置 | 缺省值 | 说明 |
|---|---|---|
name | 配置这个属性的意义在于，如果存在多个数据源，监控的时候可以通过名字来区分开来。如果没有配置，将会生成一个名字，格式是："DataSource-" + System.identityHashCode(this). 另外配置此属性至少在1.0.5版本中是不起作用的，强行设置name会出错。详情-点此处。 | |
url | 连接数据库的url，不同数据库不一样。例如： mysql : jdbc:mysql://10.20.153.104:3306/druid2 oracle : jdbc:oracle:thin:@10.20.149.85:1521:ocnauto | |
username | 连接数据库的用户名 | |
password | 连接数据库的密码。如果你不希望密码直接写在配置文件中，可以使用ConfigFilter。详细看这里 | |
driverClassName | 根据url自动识别 | 这一项可配可不配，如果不配置druid会根据url自动识别dbType，然后选择相应的driverClassName |
initialSize | 0 | 初始化时建立物理连接的个数。初始化发生在显示调用init方法，或者第一次getConnection时 |
maxActive | 8 | 最大连接池数量 |
maxIdle | 8 | 已经不再使用，配置了也没效果 |
minIdle | 最小连接池数量 | |
maxWait | 获取连接时最大等待时间，单位毫秒。配置了maxWait之后，缺省启用公平锁，并发效率会有所下降，如果需要可以通过配置useUnfairLock属性为true使用非公平锁。 | |
poolPreparedStatements | false | 是否缓存preparedStatement，也就是PSCache。PSCache对支持游标的数据库性能提升巨大，比如说oracle。在mysql下建议关闭。 |
maxPoolPreparedStatementPerConnectionSize | -1 | 要启用PSCache，必须配置大于0，当大于0时，poolPreparedStatements自动触发修改为true。在Druid中，不会存在Oracle下PSCache占用内存过多的问题，可以把这个数值配置大一些，比如说100 |
validationQuery | 用来检测连接是否有效的sql，要求是一个查询语句，常用select 'x'。如果validationQuery为null，testOnBorrow、testOnReturn、testWhileIdle都不会起作用。 | |
validationQueryTimeout | 单位：秒，检测连接是否有效的超时时间。底层调用jdbc Statement对象的void setQueryTimeout(int seconds)方法 | |
testOnBorrow | true | 申请连接时执行validationQuery检测连接是否有效，做了这个配置会降低性能。 |
testOnReturn | false | 归还连接时执行validationQuery检测连接是否有效，做了这个配置会降低性能。 |
testWhileIdle | false | 建议配置为true，不影响性能，并且保证安全性。申请连接的时候检测，如果空闲时间大于timeBetweenEvictionRunsMillis，执行validationQuery检测连接是否有效。 |
keepAlive | false （1.0.28） | 连接池中的minIdle数量以内的连接，空闲时间超过minEvictableIdleTimeMillis，则会执行keepAlive操作。 |
timeBetweenEvictionRunsMillis | 1分钟（1.0.14） | 有两个含义： 1) Destroy线程会检测连接的间隔时间，如果连接空闲时间大于等于minEvictableIdleTimeMillis则关闭物理连接。 2) testWhileIdle的判断依据，详细看testWhileIdle属性的说明 |
numTestsPerEvictionRun | 30分钟（1.0.14） | 不再使用，一个DruidDataSource只支持一个EvictionRun |
minEvictableIdleTimeMillis | 连接保持空闲而不被驱逐的最小时间 | |
connectionInitSqls | 物理连接初始化的时候执行的sql | |
exceptionSorter | 根据dbType自动识别 | 当数据库抛出一些不可恢复的异常时，抛弃连接 |
filters | 属性类型是字符串，通过别名的方式配置扩展插件，常用的插件有： 监控统计用的filter:stat 日志用的filter:log4j 防御sql注入的filter:wall | |
proxyFilters | 类型是List，如果同时配置了filters和proxyFilters，是组合关系，并非替换关系 |