RabbitMQ 3.6.1 升級至 3.7.9 版本(Windows 升級至Centos) centos安裝RabbitMQ 3.7.9 (使用RPM) Centos 7安裝RabbitMQ 3.7.8版本(單機版)-不使用RPM
隨著公司業務量的增加,原本部署在Windows伺服器的RabbitMQ叢集(3.6.1)總是出現莫名其妙的問題,經查詢官方Issue,確認是RabbitMQ 3.6.1 版本的bug。檢視從3.6.1 版本至 3.7.9 版本的變更日誌,可以發現RabbitMQ官方修復了不少bug,本著版本越新 bug相對越少且 新版本修復了當前我們經常遇到的版本bug,因此我們決定將其中一個MQ叢集(Windows)升級至3.7.9(Centos),畢竟開源軟體對於Linux的支援是更好的。
公司的業務不可能會因為要升級MQ叢集而暫停,因此採取哪種形式進行遷移是我們要重點考慮的,
- Full Stop升級
需要將整個MQ叢集停止,然後整體升級,PASS。 - 滾動升級
滾動升級對MQ的版本有要求,從3.6.1 升級至 3.7.9 不滿足官方介紹的版本要求,PASS。 - blue-green升級
blue-green升級也成為藍綠升級,升級過程不需要停止原有MQ叢集,升級過程安全可控,但需要額外搭建一個新的叢集。鑑於我們要將Windows部署的3.6.1 版本的MQ叢集升級至Centos部署的3.7.9 版本,必須新搭建叢集,因此採用該方案。
Blue-Green藍綠部署是一個升級策略,它是基於在當前叢集(blue)旁邊建立第二個叢集(green)的想法。當遷移結束後,應用程式會切換到”green”叢集,”blue”叢集會關閉,為了簡化切換,可以使用 federated queues把已排隊的訊息從“blue”傳遞高”green”叢集。
具體的搭建步驟:
1.準備Green叢集(3.7.9)
1.1 搭建3.7.9 版本的MQ叢集 。具體可參考centos安裝RabbitMQ 3.7.9 (使用RPM) 及 Centos 7安裝RabbitMQ 3.7.8版本(單機版)-不使用RPM。
1.2 Green 叢集建立完畢後匯入定義:exchange、queue、bindings。
從Blue 叢集匯出exchange、queue、bindings 的 元資料定義,匯入到新搭建的Green叢集
1.3 配置Federation Queue
Federation 作為RabbitMQ的一個外掛而存在,本質上是連線green叢集的消費者,會獲取釋出到blue叢集的訊息。 具體可參考官方文件:Upgrading RabbitMQ Using Blue-Green Deployment Strategy
將Blue 叢集設定為上游,將Green設定為下游。實現傳送至Blue叢集的訊息可以被Green叢集的消費者消費。 用武林小說中的招式就是 乾坤大挪移。
2. 切換消費者連線到Green叢集
2.1 修改客戶端連線MQ叢集地址,將消費者連線MQ叢集地址從Blue切換至Green
切換客戶端MQ連線之後,消費者會連線至Green叢集。但生產者仍舊會發送訊息至Blue叢集
3.耗盡積壓的訊息
3.1 在切換生產者連線至Green叢集之前,先耗盡Blue叢集中積壓的訊息。避免出現訊息丟失,出現不可逆轉的錯誤。
4.切換生產者連線到Green叢集
4.1 修改生產者程式MQ連線,將訊息傳送至Green叢集。
5.將Blue叢集下線
遇到的挑戰:
1.由於生產者未將連線從Blue切換至Green叢集之前,我們希望耗盡積壓的所有訊息。但由於公司業務不會停止,因此傳送端會持續的進行訊息推送,就永遠不會出現佇列訊息為空的情況。如果強行切換生產者,那麼可能會造成訊息丟失。
解決辦法:Blue叢集的消費者暫時保留,生產者從Blue切換至Green後,保留的消費者會繼續消費Blue叢集的訊息,直至消費完畢。然後就可以下線Blue叢集。
2.監控外掛通過3.6.1 版本RabbitMQ API進行資料讀取及上報,在3.7.9 中,部分API進行了調整,因此對應的監控外掛也需要對應調整。
3.此次操作是將部署在Windows的3.6.1 版本RabbitMQ 升級至 Centos 3.7.9 ,其中涉及的操作命令及部署方式均存在變化,需提前瞭解。
4.出現故障時,基本的Centos操作命令,需要了解。
附簡單的升級思路: