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、吞吐量进行验证是否正常工做。