溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章主要介紹“RocketMQ升級到主從切換的方法教程”，在日常操作中，相信很多人在RocketMQ升級到主從切換的方法教程問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”RocketMQ升級到主從切換的方法教程”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！
其主要的配置參數如下所示：
enableDLegerCommitLog 是否啟用 DLedger，即是否啟用 RocketMQ 主從切換，默認值為 false。如果需要開啟主從切換，則該值需要設置為 true 。
dLegerGroup 節點所屬的 raft 組，建議與 brokerName 保持一致，例如 broker-a。
dLegerPeers 集群節點信息，示例配置如下：n0-127.0.0.1:40911;n1-127.0.0.1:40912;n2-127.0.0.1:40913，多個節點用英文冒號隔開，單個條目遵循 legerSlefId-ip:端口，這里的端口用作 dledger 內部通信。
dLegerSelfId 當前節點id。取自 legerPeers 中條目的開頭，即上述示例中的 n0，并且特別需要強調，只能第一個字符為英文，其他字符需要配置成數字。
storePathRootDir DLedger 日志文件的存儲根目錄，為了能夠支持平滑升級，該值與 storePathCommitLog 設置為不同的目錄。
首先先搭建一個傳統意義上的主從同步架構，往集群中灌一定量的數據，然后升級到 DLedger 集群。
在 Linux 服務器上搭建一個 rocketmq 主從同步集群我想不是一件很難的事情，故本文就不會詳細介紹按照過程，只貼出相關配置。
實驗環境的部署結構采取 一主一次，其部署圖如下： 
下面我就重點貼一下 broker 的配置文件。 220 上的 broker 配置文件如下：
brokerClusterName = DefaultCluster brokerName = broker-a brokerId = 0 deleteWhen = 04 fileReservedTime = 48 brokerRole = ASYNC_MASTER flushDiskType = ASYNC_FLUSH brokerIP1=192.168.0.220 brokerIP2=192.168.0.220 namesrvAddr=192.168.0.221:9876;192.168.0.220:9876 storePathRootDir=/opt/application/rocketmq-all-4.5.2-bin-release/store storePathCommitLog=/opt/application/rocketmq-all-4.5.2-bin-release/store/commitlog autoCreateTopicEnable=false autoCreateSubscriptionGroup=false
221 上 broker 的配置文件如下：
brokerClusterName = DefaultCluster brokerName = broker-a brokerId = 1 deleteWhen = 04 fileReservedTime = 48 brokerRole = SLAVE flushDiskType = ASYNC_FLUSH brokerIP1=192.168.0.221 brokerIP2=192.168.0.221 namesrvAddr=192.168.0.221:9876;192.168.0.220:9876 storePathRootDir=/opt/application/rocketmq-all-4.5.2-bin-release/store storePathCommitLog=/opt/application/rocketmq-all-4.5.2-bin-release/store/commitlog autoCreateTopicEnable=false autoCreateSubscriptionGroup=false
相關的啟動命令如下：
nohup bin/mqnamesrv /dev/null 2>&1 & nohup bin/mqbroker -c conf/broker.conf /dev/null 2>&1 &
安裝后的集群信息如圖所示： 
DLedger 集群至少需要3臺機器，故搭建 DLedger 還需要再引入一臺機器，其部署結構圖如下： 
從主從同步集群升級到 DLedger 集群，用戶最關心的還是升級后的集群是否能夠兼容原先的數據，即原先存儲在消息能否能被消息消費者消費端，甚至于能否查詢到。 為了方便后續驗證，首先我使用下述程序向 mq 集群中添加了一篇方便查詢的消息（設置消息的key）。
public class Producer {
public static void main(String[] args) throws MQClientException, InterruptedException {
DefaultMQProducer producer = new DefaultMQProducer("producer_dw_test");
producer.setNamesrvAddr("192.168.0.220:9876;192.168.0.221:9876");
producer.start();
for(int i =600000; i < 600100; i ++) {
try {
Message msg = new Message("topic_dw_test_by_order_01",null , "m" + i,("Hello RocketMQ" + i ).getBytes(RemotingHelper.DEFAULT_CHARSET));
SendResult sendResult = producer.send(msg);
//System.out.printf("%s%n", sendResult);
} catch (Exception e) {
e.printStackTrace();
Thread.sleep(1000);
}
}
producer.shutdown();
System.out.println("end");
}
}消息的查詢結果示例如下： 
Step1：將 192.168.0.220 的 rocketmq 拷貝到 192.168.0.222，可以使用如下命令進行操作。在 192.168.0.220 上敲如下命令：
scp -r rocketmq-all-4.5.2-bin-release/ root@192.168.0.222:/opt/application/rocketmq-all-4.5.2-bin-release
> 溫馨提示：示例中由于版本是一樣，實際過程中，版本需要升級，故需先下載最新的版本，然后將老集群中的 store 目錄完整的拷貝到新集群的 store 目錄。
Step2：依次在三臺服務器的 broker.conf 配置文件中添加與 dledger 相關的配置屬性。
192.168.0.220 broker配置文件如下：
brokerClusterName = DefaultCluster brokerId = 0 deleteWhen = 04 fileReservedTime = 48 brokerRole = ASYNC_MASTER flushDiskType = ASYNC_FLUSH brokerIP1=192.168.0.220 brokerIP2=192.168.0.220 namesrvAddr=192.168.0.221:9876;192.168.0.220:9876 storePathRootDir=/opt/application/rocketmq-all-4.5.2-bin-release/store storePathCommitLog=/opt/application/rocketmq-all-4.5.2-bin-release/store/commitlog autoCreateTopicEnable=false autoCreateSubscriptionGroup=false # 與 dledger 相關的屬性 enableDLegerCommitLog=true storePathRootDir=/opt/application/rocketmq-all-4.5.2-bin-release/store/dledger_store dLegerGroup=broker-a dLegerPeers=n0-192.168.0.220:40911;n1-192.168.0.221:40911;n2-192.168.0.222:40911 dLegerSelfId=n0
192.168.0.221 broker配置文件如下：
brokerClusterName = DefaultCluster brokerName = broker-a brokerId = 1 deleteWhen = 04 fileReservedTime = 48 brokerRole = SLAVE flushDiskType = ASYNC_FLUSH brokerIP1=192.168.0.221 brokerIP2=192.168.0.221 namesrvAddr=192.168.0.221:9876;192.168.0.220:9876 storePathRootDir=/opt/application/rocketmq-all-4.5.2-bin-release/store storePathCommitLog=/opt/application/rocketmq-all-4.5.2-bin-release/store/commitlog autoCreateTopicEnable=false autoCreateSubscriptionGroup=false # 與dledger 相關的配置屬性 enableDLegerCommitLog=true storePathRootDir=/opt/application/rocketmq-all-4.5.2-bin-release/store/dledger_store dLegerGroup=broker-a dLegerPeers=n0-192.168.0.220:40911;n1-192.168.0.221:40911;n2-192.168.0.222:40911 dLegerSelfId=n1
192.168.0.222 broker配置文件如下：
brokerClusterName = DefaultCluster brokerName = broker-a brokerId = 0 deleteWhen = 04 fileReservedTime = 48 brokerRole = ASYNC_MASTER flushDiskType = ASYNC_FLUSH brokerIP1=192.168.0.222 brokerIP2=192.168.0.222 namesrvAddr=192.168.0.221:9876;192.168.0.220:9876 storePathRootDir=/opt/application/rocketmq-all-4.5.2-bin-release/store storePathCommitLog=/opt/application/rocketmq-all-4.5.2-bin-release/store/commitlog autoCreateTopicEnable=false autoCreateSubscriptionGroup=false # 與 dledger 相關的配置 enableDLegerCommitLog=true storePathRootDir=/opt/application/rocketmq-all-4.5.2-bin-release/store/dledger_store dLegerGroup=broker-a dLegerPeers=n0-192.168.0.220:40911;n1-192.168.0.221:40911;n2-192.168.0.222:40911 dLegerSelfId=n2
> 溫馨提示：legerSelfId 分別為 n0、n1、n2。在真實的生產環境中，broker配置文件中的 storePathRootDir、storePathCommitLog 盡量使用單獨的根目錄，這樣判斷其磁盤使用率時才不會相互影響。
Step3：將 store/config 下的 所有文件拷貝到 dledger store 的 congfig 目錄下。
cd /opt/application/rocketmq-all-4.5.2-bin-release/store/ cp config/* dledger_store/config/
> 溫馨提示：該步驟按照各自按照時配置的目錄進行復制即可。
Step4：依次啟動三臺 broker。
nohup bin/mqbroker -c conf/broker.conf /dev/null 2>&1 &
如果啟動成功，則在 rocketmq-console 中看到的集群信息如下： 
首先我們先驗證升級之前的消息是否能查詢到，那我們還是查找key 為 m600000 的消息，查找結果如圖所示： 
然后我們來測試一下消息發送。測試代碼如下：
public class Producer {
public static void main(String[] args) throws MQClientException, InterruptedException {
DefaultMQProducer producer = new DefaultMQProducer("producer_dw_test");
producer.setNamesrvAddr("192.168.0.220:9876;192.168.0.221:9876");
producer.start();
for(int i =600200; i < 600300; i ++) {
try {
Message msg = new Message("topic_dw_test_by_order_01",null , "m" + i,("Hello RocketMQ" + i ).getBytes(RemotingHelper.DEFAULT_CHARSET));
SendResult sendResult = producer.send(msg);
System.out.printf("%s%n", sendResult);
} catch (Exception e) {
e.printStackTrace();
Thread.sleep(1000);
}
}
producer.shutdown();
System.out.println("end");
}
}執行結果如下： 
再去控制臺查詢一下消息，其結果也表明新的消息也能查詢到。 
最后我們再來驗證一下主節點宕機，消息發送是否會受影響。
在消息發送的過程中，去關閉主節點，其截圖如下： 
再來看一下集群的狀態：
等待該復制組重新完成主服務器選舉后，即可繼續處理消息發送。
> 溫馨提示：由于本示例是一主一從，故在選舉期間，消息不可用，但在真實的生產環境上，其部署架構是多主主從，即一個復制組在 leader 選舉期間，其他復制組可以接替該復制組完成消息的發送，實現消息服務的高可用。
與 DLedger 相關的日志，默認存儲在 broker_default.log 文件中。
到此，關于“RocketMQ升級到主從切換的方法教程”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
