平滑過渡rocketmq升級方案從3.5.8升級到4.3.2 ...
背景
我們在很早之前大約在2015年8月份左右我們開始使用Rocketmq作為公司消息中間件,那個時候RocketMQ還沒有捐贈給Acaphe。
RocketMQ版本還是3.2.6,中間升級了一次版本,目前版本是3.5.8。
但是隨著RocketMQ版本不斷更新並且功能與穩定性也不斷提高,所以打算升級為4.3.X版本
上一次升級停機了10分鐘不到還是很快的,這次的目標是不停機升級版本。(題外話,上次因為升級還燃起了一波“乾架”)
架構深入瞭解
先簡單附上一張RocketMQ的整體架構圖,通過架構圖我們可以從中分析出幾種不停機版本升級方案
簡單解釋一下這個方案就是2主2從 多個nameserver,本公司架構一樣,只是節點多了點而已,3主3從 2個nameserver
通過這個架構圖我們設想了幾個錯略方案
- 新加兩台(一主一從)伺服器Broker節點升級4.3.2,然後註冊到Name Server(如果目前伺服器可以承受壓力可以不用新加),然後逐台切換最後在切換NameServer節點。
- 先替換一臺NameServer節點,然後倒入相關topic等信息,然後切換Broker節點。
- 如果方案1 2 都不能實現不停機,那就只能申請同樣資源伺服器再架設一套,最後切換IP或host(RocketMQ可以依賴hostname或IP地址所以比較麻煩,同時之前數據不好做同步)。
- 最後的防線停機維護了,違背了不停機維護的初衷。
方案實踐測試
從方案1開始進行測試,
我們將4.3.2版本的broker註冊到NameServer3.5.8的版本上出現瞭如下錯誤:
然後去看了源碼
報錯了很明顯這是兩個版本不相容有意為之,所以方案1被否定
接下來我們嘗試方案2
讓Broker3.5.8版本的節點註冊到NameServer4.3.2版本的節點,我們開始
現根據官方文檔啟動NameServer(v4.3.2)服務
sh bin/mqnamesrv
NameServer成功啟動
接下來我們啟動broker(v3.5.8)服務
sh bin/mqbroker -n IP:9876 -c conf/2m-2s-async/broker-a.properties
啟動成功,查看日誌是否有異常
沒有拋出異常,註冊成功,同時使用程式進行測試發送消息成功,這裡程式代碼就不貼上來了。
控制台也顯示正常
從上面測簡單測試來看方案2是基本可行的,接下來切換broker節點為4.3.2,看看是否文件相容
主從版本複製沒有問題,同步OK,看看消息如何,如下圖消息解析也沒有問題
接下來我們測試方案2的業務連續性
通過上面的簡單測試發現方案2可行 方案二如下
接下來開始方案二的具體實施RocketMQ各節點平滑過渡切換步驟
1、首先備份各種配置文件以防出現問題不能回滾,其中主要備份的有rocketmq程式包,store文件夾中的除commitlog文件夾外的文件(commitlog文件夾內容太多備份困難,並且從節點也有相同的一份,就沒有備份)
2、修改相關配置文件,主要針對4.3.2版本進行修改(有些不一定要改根據實際機器環境如jdk)
包括如下runserver.sh runbroker.sh 修改堆棧記憶體大小適應宿主機,還有相應的jdk環境,如果沒有設置JAVA_HOME的話
設置相關文件的可執行許可權一般有 os.sh runbroker.sh runserver.sh
命令 chmod u+x os.sh runbroker.sh runserver.sh
設置各個節點配置文件,2m-2s-async文件夾下的配置保持與上一個版本保持一致(尤其是存儲路徑store)
3、開始切換namesrv節點
首先打開namesrv節點宿主機(老版本正在運行的)執行如下命令停止namesrv
sh mqshutdown namesrv
停止成功
啟動4.3.2版本namesrv命令如下
nohup sh bin/mqnamesrv &
依次啟動多個namesrv節點,並查看日誌註意是否有異常
4、開始切換broker節點
步驟與切換namesrv類似不過broker節點有主從的概念
首先找到集群中的一臺master幾點進行切換,執行如下命令關停主節點
sh mqshutdown broker
啟動4.3.2版本broker命令如下
nohup sh bin/mqbroker -c conf/2m-2s-async/broker-b.properties &
啟動之後日誌如下
接下來進行從節點啟動切換
步驟與主節點相同
其他節點進行依次重啟切換
最後貼一張全部切換完成的圖
總結
通過上面的步驟已經接近完美的進行版本平滑升級,生產和消費幾乎感覺不到,其實在過程當中是有卡頓現象出現的
其中尤其要註意的是備份和新版本的各個配置文件要做好,否則會很惱火
同時要留意主從之間數據差距不要太大
還好我們生產環境只有6台伺服器(3m-3s)加入有十幾二十節點我手動改就要瘋了,所以使用docker部署未嘗不是一件可選方案
在這裡記錄希望對大家有參考意義