- 背景
- 症状
- 排查
- 修复
背景
最近在陆续做机房升级相关工作,配合DBA对产线数据库链接方式做个调整,将原来直接链接读库的地址切换到统一的读负载均衡的代理 haproxy 上,方便机柜和服务器的搬迁。
切换之后线上时不时的会发生 discard connection 错误,导致程序报 500 错误,但不是每次都必现的。
开发框架: spring boot+mybatis+druid+shardingJDBC
网络架构:
appserver->mysql(master) 写
appserver->haproxy->mysql(slave)/n 读
第一反应肯定是因为这次的读库地址的变动引起的问题,觉得问题应该是 druid 链接池中的 connection 保活策略没起作用,只要做下配置修改应该就可以了。结果这个问题让我们排查了好几天,我们竟然踩到了千年难遇的深坑。
这个问题排查的很坎坷,一次次的吐血,最终我们定位到问题并且优雅的修复了,我们一起来体验下这个一次一次让你绝望一次一次打脸的过程。
症状
先说故障症状,经常出现如下错误:
discard connection
com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure
The last packet successfully received from the server was 72,557 milliseconds ago. The last packet sent successfully to the server was 0 milliseconds ago.
根据错误日志初步判断肯定是与 db 之间的链接已经断开,尝试使用了一个已经断开的链接才会引起这个错误发生。但是根据我们对 druid 了解,druid 有链接检查功能,按理不会拿到一个无效链接才对,带着这个线索我们上路了。
排查
为了准确的知道 db 的链接的存活时间,了解到 haproxy 对转发的 db tcp 链接空闲时间在 1m 之内,超过 1m 不活动就会被关掉。也就说我们与 db 之间的原来的长链接在 1m 之内会被断开。我们先不管这个时间设置的是否符合所有的大并发场景,至少在 druid 的链接池里会有有效链接检查,应该不会拿到无效链接才对,我们做了配置调整。
我们看下 druid 跟链接时间相关的配置:
datasource.druid.validationQuery=SELECT 1
datasource.druid.validationQueryTimeout=2000
datasource.druid.testWhileIdle=true
datasource.druid.minEvictableIdleTimeMillis=100000
datasource.druid.timeBetweenEvictionRunsMillis=20000
配置的每项的意思这里就不解释了。
我们启用了 testWhileIdle 配置,让每次拿取链接的时候发起检查。根据 timeBetweenEvictionRunsMillis 的配置只有大于这个时间 druid 才会发起检查,所以可能的场景是拿到一个即将过期的链接,根据这个线索我们调整这个时间为 20000ms,也就是超过 20s 会检查当前拿取的链接确定是否有效,检查的方式应该是使用 validationQuery 配置的 sql 语句才对,但是发现我们并找不到任何有关于 SELECT 1 的痕迹。
为什么你死活找不到 SELECT 1
首先要搞清楚 validationQuery 为什么没起作用,带着这个疑问开始 debug druid 源码。
if (isTestWhileIdle()) {
final long currentTimeMillis = System.currentTimeMillis();
final long lastActiveTimeMillis = poolableConnection.getConnectionHolder().getLastActiveTimeMillis();
final long idleMillis = currentTimeMillis - lastActiveTimeMillis;
long timeBetweenEvictionRunsMillis = this.getTimeBetweenEvictionRunsMillis();
if (timeBetweenEvictionRunsMillis <= 0) {
timeBetweenEvictionRunsMillis = DEFAULT_TIME_BETWEEN_EVICTION_RUNS_MILLIS;
}
if (idleMillis >= timeBetweenEvictionRunsMillis) {
boolean validate = testConnectionInternal(poolableConnection.getConnection());
if (!validate) {
if (LOG.isDebugEnabled()) {
LOG.debug("skip not validate connection.");
}
discardConnection(realConnection);
continue;
}
}
}
}
闲置时间肯定会有大于 timeBetweenEvictionRunsMillis 时间的,会发起 testConnectionInternal 方法检查。我们继续跟进去看,
protected boolean testConnectionInternal(DruidConnectionHolder holder, Connection conn) {
boolean valid = validConnectionChecker.isValidConnection(conn, validationQuery, validationQueryTimeout);
内部会使用 validConnectionChecker 检查对象发起检查。
public boolean isValidConnection(Connection conn, String validateQuery, int validationQueryTimeout) throws Exception {
if (conn.isClosed()) {
return false;
}
if (usePingMethod) {
if (conn instanceof DruidPooledConnection) {
conn = ((DruidPooledConnection) conn).getConnection();
}
if (conn instanceof ConnectionProxy) {
conn = ((ConnectionProxy) conn).getRawObject();
}
if (clazz.isAssignableFrom(conn.getClass())) {
if (validationQueryTimeout < 0) {
validationQueryTimeout = DEFAULT_VALIDATION_QUERY