MQ:Communications link failure

ActiveMQ：Communications link failure問題以及解決辦法

 

ActiveMQ版本：5.5.1

MQ 所使用的 MySQL 是 InnoDB存儲引擎

記錄人：@鄭昀

現象：

業務表面現象：無。系統現象：無。

日誌信息：業務系統發送 MQ 消息時，下面這種錯誤日誌斷斷續續地一直都有：

com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure   The last packet successfully received from the server was 60,001 milliseconds ago.  The last packet sent successfully to the server was 0 milliseconds ago.

 

緣由：

ActiveMQ 持久化方案咱們選的是 MySQL 。

MySQL 的全局變量 wait_timeout 默認是28800，單位是秒，即8小時。

運維部早先在測試 ActiveMQ 5.5 主從方案時，發現當 Master 宕機後，鎖（數據庫裏的一個排他鎖）有可能沒有釋放，致使 Slave 沒法成爲 Master（ 這是 ActiveMQ 5.5 的 BUG，已在 5.6.0和5.7.0 修復）。

因此運維部將 wait_timeout 參數調短爲了60秒，但願能加速鎖釋放。

當業務不繁忙時，也許會有60秒既不生產也不消費，所以 MySQL 主動斷開了 Connection 。此時，若是做爲 MySQL Client 身份的 Broker Service，它的數據庫鏈接池對  鏈接斷開檢測和自動重連 作得很差的話，那麼 Broker 首次訪問 DB 時 jdbc 就會報錯。

 

短時間解決辦法：

將 ActiveMQ 所使用的 MySQL 的全局變量 wait_timeout 恢復爲默認值 28800 。（已完成）

 

中期解決方法：

將 ActiveMQ 升級到 5.6.0或5.7.0 穩定版本。

---

相關的BUG：

ActiveMQ 的缺陷單  AMQ-1958 報告：

JDBC master/slave deadlock when connection is lost      

影響版本：  4.1.2, 5.0.0, 5.1.0, 5.2.0

Fix版本： 5.6.0

狀態：2012年4月17日已修復

描述：

在一個純 JDBC Failover 場景下（ 1 Master+1 Slave）：若是 Master 失去了數據庫網絡鏈接，數據庫裏的鎖將不會釋放。這樣 Slave 不知道 Master 已不能執行任務，Slave 仍嘗試不斷獲取鎖；當 Master 重啓後，它本身也沒法得到鎖，因而變身爲 Slave；結果就是  0 Master+2 Slave 。

環境：Oracle 10，MySQL 5

（這也就是運維部在 ActiveMQ 5.5.1 測試場景所遇到的）

 

AMQ-3654 也報告相似問題：

JDBC Master/Slave : Slave cannot acquire lock when the master loose database connection

影響版本： 5.5.0

Fix版本： 5.7.0

狀態：2012年6月13日已修復

描述：與 AMQ-3654 描述同樣。只不過報告的版本號不同。

 

 

---

參考資源：

1）火丁老王， MySQL裏的wait_timeout

『wait_timeout 過大有弊端，其體現就是 MySQL 裏大量的 SLEEP 進程沒法及時釋放，拖累系統性能，不過也不能把這個指設置的太小，不然你可能會遭遇到「MySQL has gone away」之類的問題。』

『在MySQL命令行裏經過 SET來設置便可，避免服務重啓：

mysql> set global wait_timeout=60;』

『查有無生效，用 show global variables 查全局變量：

mysql> show global variables like 'wait_timeout';

單純使用 show variables 的話就等同於使用的是 show session variables，查詢的是會話變量，你會誤覺得設置沒有生效。

』

2）iteye， 關於 MySQL 的 wait_timeout 鏈接超時報錯解決方案

3） AMQ-1958

4）之前有人提議在數據庫鏈接字符串中增長autoReconnect=true&failOverReadOnly=false，但這隻對 MySQL 4.0 之前的版本有效，對 MySQL 5.0 之後無效。

5） ActiveMQ JDBC Master Slave幫助

『

Master failure

If the master looses connection to the database or looses the exclusive lock then it immediately shuts down. If a master shuts down or fails, one of the other slaves will grab the lock and so the topology switches to the following diagram

』

6）wait_timeout 參數說明

『參數含義：服務器關閉非交互鏈接以前等待活動的秒數。

在線程啓動時，根據全局wait_timeout值或全局interactive_timeout值初始化會話wait_timeout值，取決於客戶端類型(由mysql_real_connect()的鏈接選項CLIENT_INTERACTIVE定義)。 

參數默認值： 28800秒（8小時）』

 

本文引自：http://www.cnblogs.com/zhengyun_ustc/archive/2012/11/10/activemq_wait_timeout.html