Atomikos + druid 多數據源數據庫連接超時回收問題怎么解決

Atomikos + druid 多數據源數據庫連接超時回收問題怎么解決，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細講解，有這方面需求的人可以來學習下，希望你能有所收獲。

異常表現

一段時間不查詢數據，通常是過一夜第二天一早發起第一次連接時會出現數據庫無法連接異常:

//通常會出現下面錯誤，異常情況一：
com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: The last packet successfully received from the server was 37,350,882 milliseconds ago.  The last packet sent successfully to the server was 37,350,882 milliseconds ago. is longer than the server configured value of 'wait_timeout'. You should consider either expiring and/or testing connection validity before use in your application, increasing the server configured values for client timeouts, or using the Connector/J connection property 'autoReconnect=true' to avoid this problem.

//異常情況二：
ERROR [com.alibaba.druid.pool.DruidPooledStatement:357] - CommunicationsException, druid version 1.1.10, jdbcUrl : jdbc:mysql://XX.XX.XX.XX:3306/txsmarthome?useUnicode=true&characterEncoding=utf8&useSSL=false&allowMultiQueries=true&noAccessToProcedureBodies=true&autoReconnect=true&failOverReadOnly=false&pinGlobalTxToPhysicalConnection=true, testWhileIdle true, idle millis 39540140, minIdle 50, poolingCount 0, timeBetweenEvictionRunsMillis 60000, lastValidIdleMillis 39540140, driver com.mysql.jdbc.Driver, exceptionSorter com.alibaba.druid.pool.vendor.MySqlExceptionSorter

//異常情況三：
java.sql.SQLException: connection holder is null

druid 異常

出現上述前兩個異常是由于數據庫連接超過mysql配置的 wait_timeout 時間，連接被mysql回收，但是 druid 連接池并不知道連接已被回收，因此報錯。

連接池都有失敗重連功能，druid的做法是在下一次請求連接數據庫時，重連上一個異常的連接，所以之后的每次請求都是異常，直到池中所有連接都重連一次。即連續失敗次數就是 minIdle 配置的數量。

如果連接多數據庫情況，每個數據庫的請求都會連接失敗 minIdle 次。

連接池配置

spring:
    datasource:
        druid:
            db1:
                # 每隔1小時檢查數據庫連接是否有效，連接成功1分鐘后開始計時
                removeAbandonedTimeout: 3600
                # 如果連接失效就刪重連
                removeAbandoned: true
                # 刪除時輸出日志
                logAbandoned: true
                # 測試查詢查詢結果
                testOnReturn: true

上述配置可保證限時刪除無效連接。

數據庫配置

命令行連接數據庫后，執行：show global variables like "%timeout%";

mysql> show global variables like "%timeout%";
+-----------------------------+----------+
| Variable_name               | Value    |
+-----------------------------+----------+
| connect_timeout             | 10       |
| delayed_insert_timeout      | 300      |
| have_statement_timeout      | YES      |
| innodb_flush_log_at_timeout | 1        |
| innodb_lock_wait_timeout    | 7200     |
| innodb_rollback_on_timeout  | OFF      |
| interactive_timeout         | 3600     |
| lock_wait_timeout           | 31536000 |
| net_read_timeout            | 30       |
| net_write_timeout           | 60       |
| rpl_stop_slave_timeout      | 31536000 |
| slave_net_timeout           | 60       |
| wait_timeout                | 3600     |
+-----------------------------+----------+

上述數據庫的鏈接有效時間是1小時，mysql默認為8小時，可使用命令修改，無須重啟mysql：

# 修改為12小時，注意下面兩個配置項要一致才能生效
mysql> set global interactive_timeout=43200;
Query OK, 0 rows affected

mysql> set global wait_timeout=43200;
Query OK, 0 rows affected

需要注意 鏈接池 removeAbandonedTimeout <= 數據庫 wait_timeout。

atomikos 異常

異常情況三的場景更復雜一些， atomikos 工作在 druid 上層，當druid檢測到超時鏈接并重連后，并不會通知 atomikos，所以下次sql執行時仍然會報錯。

atomikos 資料較少，看源碼太費時，有空了再研究。

解決方案

1. 盡量增大數據庫 wait_timeout 的時間（需要注意過大的 wait_timeout 會影響數據回收無效鏈接）。

2. 可關閉druid removeAbandoned 功能。

3. 配置一個定時器，在 min(wait_timeout,removeAbandonedTimeout) 時間內至少執行 minIdle 次，每次都在所有數據源中執行一個簡單的查詢。

三種方式可結合使用

升級 mysql-jdbc-driver 到6以上據說也可以解決，沒有測試過。

看完上述內容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注億速云行業資訊頻道，感謝您對億速云的支持。