设为首页 收藏本站
查看: 1608|回复: 0

[经验分享] 一个MySQL-JDBC驱动bug引起的血案……

[复制链接]

尚未签到

发表于 2018-9-27 07:06:51 | 显示全部楼层 |阅读模式
  问题背景
  公司是做电商系统的,整个系统搭建在华为云上。系统设计的时候,考虑到后续的用户和订单数量比较大,需要使用一些大数据库的组件。关系型数据库这块,考虑到后续数据量的快速增长,不是直接写入MySQL,而是使用了华为云的分布式数据库中间件DDM。使用了DDM之后,可以在业务不感知的情况下,直接增加MySQL读实例的个数,线性提升读性能。也支持中间件层面的分库分表,提供海量关系型数据库的操作。简直是为电商系统贴身定制的。
  DDM自身是以集群形式提供服务的,对业务开放的是多个连接IP地址。需要有一层负载均衡。如果使用传统的加LB的形式做负载均衡,会多一层中转,有性能损耗。所以,直接使用了MySQL-JDBC提供的客户端负载均衡能力。
  逻辑结构如下图所示:
DSC0000.jpg

  ▲业务通过MySQL-JDBC的Loadbalance能提访问多个DDM节点。MySQL-JDBC提供负载均衡能力。
  问题说明
  MySQL JDBC驱动的客户端负载均衡能力,一直运行得好好,性能嗷嗷叫。可是前一阵子竟无故出现业务请求失败。我是负责电商订单模块的,涉及到真实的Money,这个问题可吓了宝宝一身冷汗……
  于是赶紧查看了后台日志,发现是访问DDM出现了异常,二话不说直接提了工单给华为云DDM服务。
DSC0001.jpg

  不得不说,华为云的服务还是很好的,不到半个小时就有专门的工作人员联系了我,还跟我一起排查问题。将我们业务的日志取下来,和DDM的支撑人员一起分析,发现报错如下:根本原因竟然是MySQL驱动的bug,导致StackOverflow本地栈溢出导致……原来是一个Bug引发的血案,误会了DDM服务,真是抱歉了……
DSC0002.jpg

DSC0003.jpg

  从堆栈可以看出来,某个异常,触发了MySQL-JDBC的bug,导致循环调用,直至栈溢出。在华为DDM支撑人员的建议下,对驱动代码进行了反编译,从反编译的情况下,可以看到的确是存在循环嵌套的可能。
  Loadbalance轮询连接 –>同步新老连接的状态 ->发送sql给服务端 -> Loadbalance轮询连接。
  相关代码如下:
  com/mysql/jdbc/LoadBalancedConnectionProxy.java的pickNewConnection()函数
  for (int hostsTried = 0, hostsToTry = this.hostList.size(); hostsTried < hostsToTry; hostsTried++) {
  ConnectionImpl newConn = null;
  try {
  newConn = this.balancer.pickConnection(this, Collections.unmodifiableList(this.hostList), Collections.unmodifiableMap(this.liveConnections),
  this.responseTimes.clone(), this.retriesAllDown);
  

    if (this.currentConnection != null) {  if (pingBeforeReturn) {
  if (pingTimeout == 0) {
  newConn.ping();
  } else {
  newConn.pingInternal(true, pingTimeout);
  }
  }
  

  syncSessionState(this.currentConnection, newConn);
  }
  

  this.currentConnection = newConn;
  return;
  

  
} catch (SQLException e) {
  if (shouldExceptionTriggerConnectionSwitch(e) && newConn != null) {
  // connection error, close up shop on current connection
  invalidateConnection(newConn);
  }
  
}
  

  }
  syncSessionState()函数,在执行完SQL之后,又会调用postProcess()函数,如此嵌套循环就来了。
  if (!this.conn.getAutoCommit()) {
  this.matchingAfterStatementCount = 0;
  // auto-commit is enabled:
  } else {
  

if (this.proxy == null && this.conn.isProxySet()) {  MySQLConnection lcl_proxy = this.conn.getMultiHostSafeProxy();
  while (lcl_proxy != null && !(lcl_proxy instanceof LoadBalancedMySQLConnection)) {
  lcl_proxy = lcl_proxy.getMultiHostSafeProxy();
  }
  if (lcl_proxy != null) {
  this.proxy = ((LoadBalancedMySQLConnection) lcl_proxy).getThisAsProxy();
  }
  

  
}
  

  
if (this.proxy != null) {
  // increment the match count if no regex specified, or if matches:
  if (this.matchingAfterStatementRegex == null || sql.matches(this.matchingAfterStatementRegex)) {
  this.matchingAfterStatementCount++;
  }
  
}
  
// trigger rebalance if count exceeds threshold:
  
if (this.matchingAfterStatementCount >= this.matchingAfterStatementThreshold) {
  this.matchingAfterStatementCount = 0;
  try {
  if (this.proxy != null) {
  this.proxy.pickNewConnection();
  }
  

  } catch (SQLException e) {
  // eat this exception, the auto-commit statement completed, but we could not rebalance for some reason.  User may get exception when using
  // connection next.
  }
  
}
  

  }
  这么明显的bug,不太相信MySQL会没有发现。当前我们使用的是5.1.44版本的驱动,查看了下最新的5.1.66的代码,发现的确是修复了这个问题的,代码如下:
  public ResultSetInternalMethods postProcess(String sql, Statement interceptedStatement, ResultSetInternalMethods originalResultSet, Connection connection,
  int warningCount, boolean noIndexUsed, boolean noGoodIndexUsed, SQLException statementException) throws SQLException {
  

// Don't count SETs neither SHOWs. Those are mostly used internally and must not trigger a connection switch.  
if (!this.countStatements || StringUtils.startsWithIgnoreCase(sql, "SET") || StringUtils.startsWithIgnoreCase(sql, "SHOW")) {
  return originalResultSet;
  
}
  

  通过过滤掉SET和SHOW语句,避免了循环嵌套的发生。但是5.1.66又引入了新的bug,由于并不是每个调用postProcess的地方都有SQL,这里的代码会抛空指针异常。MySQL JDBC的开发者都不做测试的吗……
  没办法,分析了下5.1.44的代码,发现通过适当的调整loadBalanceAutoCommitStatementThreshold这个参数的数值,也可以避免循环嵌套的发生。我们的环境改成了5,修改之后,平稳运行1周,没再出现过问题。
  
  修改方案
  loadBalanceAutoCommitStatementThreshold修改成了5,但是引入的问题是,如果业务包含一些比较耗时的SQL,可能会导致DDM的负载不均衡。不过,就目前情况来看,DDM的性能还是比较强劲的~点击这里,免费体验一番吧!



运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-602500-1-1.html 上篇帖子: Linux下的MYSQL主主复制 下篇帖子: 【MySQL】【安全】探讨MySQL备份所需最小权限
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表