网创优客建站品牌官网
为成都网站建设公司企业提供高品质网站建设
热线:028-86922220
成都专业网站建设公司

定制建站费用3500元

符合中小企业对网站设计、功能常规化式的企业展示型网站建设

成都品牌网站建设

品牌网站建设费用6000元

本套餐主要针对企业品牌型网站、中高端设计、前端互动体验...

成都商城网站建设

商城网站建设费用8000元

商城网站建设因基本功能的需求不同费用上面也有很大的差别...

成都微信网站建设

手机微信网站建站3000元

手机微信网站开发、微信官网、微信商城网站...

建站知识

当前位置:首页 > 建站知识

MySQLJDBC驱动bug怎么解决-创新互联

本篇内容介绍了“MySQL JDBC驱动bug怎么解决”的有关知识,在实际案例的操作过程中,不少人都会遇到这样的困境,接下来就让小编带领大家学习一下如何处理这些情况吧!希望大家仔细阅读,能够学有所成!

创新互联建站是一家集网站建设,江口企业网站建设,江口品牌网站建设,网站定制,江口网站建设报价,网络营销,网络优化,江口网站推广为一体的创新建站企业,帮助传统企业提升企业形象加强企业竞争力。可充分满足这一群体相比中小企业更为丰富、高端、多元的互联网需求。同时我们时刻保持专业、时尚、前沿,时刻以成就客户成长自我,坚持不断学习、思考、沉淀、净化自己,让我们为更多的企业打造出实用型网站。

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

     } 
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) {

         if 
(this.matchingAfterStatementRegex == 
null 
|| sql.matches(this.matchingAfterStatementRegex)) {

             
this.matchingAfterStatementCount++;

         }

     }

     if 
(this.matchingAfterStatementCount >= 
this.matchingAfterStatementThreshold) {

         
this.matchingAfterStatementCount = 
;

         
try 
{

             
if 
(this.proxy != 
null) {

                 
this.proxy.pickNewConnection();

             }

 

         } 
catch 
(SQLException e) {

             }

     }

 }

这么明显的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 {

 

     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性能比较强劲。

“MySQL JDBC驱动bug怎么解决”的内容就介绍到这里了,感谢大家的阅读。如果想了解更多行业相关的知识可以关注创新互联-成都网站建设公司网站,小编将为大家输出更多高质量的实用文章!


文章名称:MySQLJDBC驱动bug怎么解决-创新互联
URL链接:http://bjjierui.cn/article/ceggdp.html

其他资讯