溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
本篇內容介紹了“MySQL JDBC驅動bug怎么解決”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！
公司是做電商系統的，整個系統搭建在華為云上。系統設計的時候，考慮到后續的用戶和訂單數量比較大，需要使用一些大數據庫的組件。關系型數據庫這塊，考慮到后續數據量的快速增長，不是直接寫入MySQL，而是使用了華為云的分布式數據庫中間件DDM。
使用了DDM之后，可以在業務不感知的情況下，直接增加MySQL讀實例的個數，線性提升讀性能。也支持中間件層面的分庫分表，提供海量關系型數據庫的操作。簡直是為電商系統貼身定制的。
DDM自身是以集群形式提供服務的，對業務開放的是多個連接IP地址。需要有一層負載均衡。如果使用傳統的加LB的形式做負載均衡，會多一層中轉，有性能損耗。所以，直接使用了MySQL-JDBC提供的客戶端負載均衡能力。
業務通過MySQL-JDBC的Loadbalance能提訪問多個DDM節點。MySQL-JDBC提供負載均衡能力。
使用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周，沒再出現過問題。
loadBalanceAutoCommitStatementThreshold修改成了5，但是引入的問題是，如果業務包含一些比較耗時的SQL，可能會DDM的負載不均衡。不過，目前看來還好，DDM性能比較強勁。
“MySQL JDBC驅動bug怎么解決”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
