RocketMQ三主三從二命名服務平滑版本升級實操

​本文介紹本次進行RocketMQ平滑過渡升級的實際操做

前文已經介紹過了升級基本原理，主要思想就是先升級NameSrv（命名服務）而後在升級broker節點。broker節點先升級master節點而後再升級slave節點。

 

咱們先看下RocketMQ架構圖

 

這裏介紹實際操做是怎麼樣。

首先介紹咱們使用RocketMQ實際架設的狀況。

主機一共6臺分別是：

    10.10.10.1~10.10.10.6

 

三主三從分別在這六臺機器上，其中有兩臺部署了broker和namesrv（沒錯實際狀況就是這樣）

 

第一階段準備文件

 

實際操做步驟以下：

一、可執行文件準備

根據主機實際狀況先將RocketMQ執行文件分別上傳到六臺服務器

    解壓  

unzip rocketmq-all-4.4.0-bin-release.zip

    注意：這裏主要看你的解壓目錄，若是配置文件沒有指定rocketmq使用的文件目錄，通常默認和rocketmq-all-4.4.0-bin-release這個文件夾相同的目錄的，若是執行目錄，須要設置相同目錄

 

二、編輯並上傳配置文件

    由於是三主三從異步刷盤數據模式，因此在

    rocketmq-all-4.4.0-bin-release/conf/2m-2s-async/目錄設置好配置文件，以下圖所示

配置文件內容這裏根據實際狀況添加，本人會把多有配置都放在配置文件裏，其中包括namesrvAddr 這個配置選項。

    

    而後修改對應可執行文件的內存設置

    修改sh腳本jvm內存限制（根據本身實際狀況），若是你有指定jdk/jre環境的話能夠在這裏指定路徑

 

   

三、設置腳本的可執行權限

一下三個文件須要設置可執行權限

    設置權限主要是以下幾個命令

chgrp rocketmq rocketmq-all-4.4.0-bin-release -R #設置文件及子文件的用戶組chown rocketmq rocketmq-all-4.4.0-bin-release -R #設置可執行文件及子文件的擁有者

    設置了用戶和用戶組以後也能夠忽略設置可執行權限

 

第二階段升級namesrv服務

 

    若是第一階段內容都沒有問題那麼咱們開始執行升級namesrv服務

 

一、namesrv服務我是部署在10.10.10.1和10.10.10.2這兩臺服務器的

 

su - rocketmq #切換用戶​
cd alibaba-rocketmq/ #進入3.4.8版本文件還行目錄​
sh bin/mqshutdown namesrv #中止namesrv服務
​cd ../rocketmq-all-4.4.0-bin-release/ #進入到4.4版本目錄
​nohup sh bin/mqnamesrv -c conf/nameserver.properties & #啓動新namesrv服務​
tail -f ~/logs/rocketmqlogs/namesrv.log #啓動以後驗證服務是否正常啓動
​sh  bin/mqadmin clusterList -n 10.10.10.1:9876 #驗證服務列表是否聯通​

    上述過程若是沒有問題繼續進行下一臺namesrv升級切換（等待一切正常以後在處理）

第二臺服務器10.10.10.2重複剛纔的動做，切換完成就再看看生產消費狀況，若是一切正常，咱們就完成了namesrv的切換操做。

 

nameserver.properties 配置文件件屬性以下：

eEpollNativeSelector=true #這個屬性以前一直不能處理4.4版本剛修復的bug

orderMessageEnable=true

    

 

第三階段 升級broker節點

 

升級broker節點是重中之重，消息隊列數據主要都在這裏進行交互，一單失敗不要着急，集羣多節點是有負載的。不過儘可能在不是業務高峯期的時候來升級broker節點。

    先升級master而後在升級對應的slave節點

 

下面開始升級broker節點

cd alibaba-rocketmq/ #進入以前版本目錄​
sh bin/mqshutdown broker #中止broker節點

​cd ../rocketmq-all-4.4.0-bin-release/ #進入新版本目錄

​nohup sh bin/mqbroker -c conf/2m-2s-async/broker-a.properties & #啓動新版本broker服務

​sh bin/mqadmin clusterList -n 10.10.10.1:9876 #檢查
#或

sh bin/mqadmin clusterList -n 10.10.10.2:9876 #檢查

而後執行此節點的slave節點broker（注意配置文件替換）

nohup sh bin/mqbroker -c conf/2m-2s-async/broker-a.properties &
nohup sh bin/mqbroker -c conf/2m-2s-async/broker-a-s.properties &
nohup sh bin/mqbroker -c conf/2m-2s-async/broker-b.properties &
nohup sh bin/mqbroker -c conf/2m-2s-async/broker-b-s.properties &
nohup sh bin/mqbroker -c conf/2m-2s-async/broker-c.properties &
nohup sh bin/mqbroker -c conf/2m-2s-async/broker-c-s.properties &

而後檢查各個節點狀況（注意：啓動節點的之後要觀察剛剛啓動的節點是否正常工做以後在進行其餘節點的升級啓動工做，有些數據量大的節點會啓動很慢。）

觀察沒問題各個節點都比較正常這個時候證實升級成功

總結

    升級的時候不要着急，一個節點一個節點的進行升級，先升級master節點，在升級slave節點。升級完一個節點經過日誌、namesrv、吞吐量進行驗證是否正常工做。