ITPub博客
首页 博客 专栏 学院 社区 IT新媒体评选
发博

首页 > 数据库 > 数据库开发技术 > 一个MySQL JDBC驱动bug引起的血案

一个MySQL JDBC驱动bug引起的血案

原创 数据库开发技术 作者：PaaS小魔仙 时间：2018-08-16 10:21:05 0 删除 编辑

1.1       问题背景

公司是做电商系统的，整个系统搭建在华为云上。系统设计的时候，考虑到后续的用户和订单数量比较大，需要使用一些大数据库的组件。关系型数据库这块，考虑到后续数据量的快速增长，不是直接写入 MySQL ，而是使用了华为云的分布式数据库中间件 DDM 。

使用了 DDM 之后，可以在业务不感知的情况下，直接增加 MySQL 读实例的个数，线性提升读性能。也支持中间件层面的分库分表，提供海量关系型数据库的操作。简直是为电商系统贴身定制的。

DDM 自身是以集群形式提供服务的，对业务开放的是多个连接 IP 地址。需要有一层负载均衡。如果使用传统的加 LB 的形式做负载均衡，会多一层中转，有性能损耗。所以，直接使用了 MySQL-JDBC 提供的客户端负载均衡能力。逻辑结构如下图所示：

 


 

业务通过 MySQL-JDBC 的 Loadbalance 能提访问多个 DDM 节点。 MySQL-JDBC 提供负载均衡能力。

 

1.2       问题说明

使用 MySQL 客户端负载均衡力能，一直运行得好好，性能嗷嗷叫。可是前一阵子，无故出现了业务请求失败。我是负责电商订单模块的，涉及到真实的 Money ，这个问题吓了宝宝一身冷汗。。赶紧查看后台日志，发现是访问 DDM 出现了异常，二话不说直接提了工单给华为云 DDM 服务。

[WARN] [2018-07-08 23:11:29] [ MySqlValidConnectionChecker :isValidConnection()] [DubboServerHandler-172.31.0.146:8080-thread-64-txId=00000000657615aa] Unexpected error in ping

java.lang.reflect.InvocationTargetException

         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)

         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)

         at java.lang.reflect.Method.invoke(Method.java:498)

         at com.alibaba.druid.pool.vendor.MySqlValidConnectionChecker.isValidConnection(MySqlValidConnectionChecker.java:98)

         at com.alibaba.druid.pool.DruidAbstractDataSource.testConnectionInternal(DruidAbstractDataSource.java:1252)

         at com.alibaba.druid.pool.DruidDataSource.getConnectionDirect(DruidDataSource.java:981)

 

不得不说，华为云的服务还是很好的，不到半个小时就联系了我，还跟我一起排查问题。

将我们业务的日志取下来，和 DDM 的支撑人员一起分析，发现报错如下：

根本原因竟然是 MySQL 驱动的 bug ，导致 StackOverflow 本地栈溢出导致，真是误会了 DDM 服务，抱歉了。

Caused by: java.lang.StackOverflowError

         at com.mysql.jdbc.StringUtils.getBytes(StringUtils.java:2360)

         at com.mysql.jdbc.StringUtils.getBytes(StringUtils.java:2344)

         at com.mysql.jdbc.StringUtils.getBytes(StringUtils.java:568)

         at com.mysql.jdbc.StringUtils.getBytes(StringUtils.java:626)

         at com.mysql.jdbc.Buffer.writeStringNoNull(Buffer.java:670)

         at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2636)

         at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2483)

         at com.mysql.jdbc.ConnectionImpl.setReadOnlyInternal(ConnectionImpl.java:4961)

         at com.mysql.jdbc.ConnectionImpl.setReadOnly(ConnectionImpl.java:4954)

         at com.mysql.jdbc.MultiHostConnectionProxy.syncSessionState(MultiHostConnectionProxy.java:381)

         at com.mysql.jdbc.MultiHostConnectionProxy.syncSessionState(MultiHostConnectionProxy.java:366)

         at com.mysql.jdbc.LoadBalancedConnectionProxy. pickNewConnection (LoadBalancedConnectionProxy.java:344)

         at com.mysql.jdbc.LoadBalancedAutoCommitInterceptor.postProcess(LoadBalancedAutoCommitInterceptor.java:104)

         at com.mysql.jdbc.MysqlIO.invokeStatementInterceptorsPost(MysqlIO.java:2885)

         at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2808)

         at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2483)

         at com.mysql.jdbc.ConnectionImpl.setReadOnlyInternal(ConnectionImpl.java:4961)

         at com.mysql.jdbc.ConnectionImpl.setReadOnly(ConnectionImpl.java:4954)

         at com.mysql.jdbc.MultiHostConnectionProxy.syncSessionState(MultiHostConnectionProxy.java:381)

         at com.mysql.jdbc.MultiHostConnectionProxy.syncSessionState(MultiHostConnectionProxy.java:366)

         at com.mysql.jdbc.LoadBalancedConnectionProxy. pickNewConnection (LoadBalancedConnectionProxy.java:344)

         at com.mysql.jdbc.LoadBalancedAutoCommitInterceptor.postProcess(LoadBalancedAutoCommitInterceptor.java:104)

         at com.mysql.jdbc.MysqlIO.invokeStatementInterceptorsPost(MysqlIO.java:2885)

。。。 此处省略 10000 行。。

从堆栈可以看出来，某个异常，触发了 MySQL-JDBC 的 bug ，导致循环调用，直至栈溢出。

在华为 DDM 支撑人员的建议下，对驱动代码进行了反编译，从反编译的情况下，可以看到，的确是存在循环嵌套的可能。

Loadbalance 轮询连接 –> 同步新老连接的状态 -> 发送 sql 给服务端 -> Loadbalance 轮询连接。

相关代码如下：

com/mysql/jdbc/LoadBalancedConnectionProxy.java 的 pickNewConnection() 函数

for ( int hostsTried = , 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 == ) {
                    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 = 




;


     



// 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 = 




;


         


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 周，没再出现过问题。

 

1.3       修改方案

loadBalanceAutoCommitStatementThreshold 修改成了 5 ，但是引入的问题是，如果业务包含一些比较耗时的 SQL ，可能会 DDM 的负载不均衡。不过，目前看来还好， DDM 性能比较强劲。


来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/31543630/viewspace-2200174/ ，如需转载，请注明出处，否则将追究法律责任。

0
0
上一篇： 不吹不黑，赞一下应用运维管理的cassacdra
下一篇： 立体运维架构与定位
请登录后发表评论 登录
全部评论
PaaS小魔仙

注册时间：2018-06-25

  • 博文量
    33
  • 访问量
    37168

最新文章

支持我们 作者招募 用户协议 FAQ Contact Us

北京盛拓优讯信息技术有限公司. 版权所有  京ICP备16024965号-8 北京市公安局海淀分局网监中心备案编号：11010802021510 niuxiaotong@pcpop.com 17352615567 未成年人举报专区

广播电视节目制作经营许可证(京) 字第1234号 中国互联网协会会员

违法和不良信息举报电话:18101376593