RocketMQ三主三从二命名服务平滑版本升级实操

​本文介绍本次进行RocketMQ平滑过渡升级的实际操作

前文已经介绍过了升级基本原理，主要思想就是先升级NameSrv（命名服务）然后在升级broker节点。broker节点先升级master节点然后再升级slave节点。

 

我们先看下RocketMQ架构图

 

这里介绍实际操作是怎么样。

首先介绍我们使用RocketMQ实际架设的情况。

主机一共6台分别是：

    10.10.10.1~10.10.10.6

 

三主三从分别在这六台机器上，其中有两台部署了broker和namesrv（没错实际情况就是这样）

 

第一阶段准备文件

 

实际操作步骤如下：

1、可执行文件准备

根据主机实际情况先将RocketMQ执行文件分别上传到六台服务器

    解压  

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

    注意：这里主要看你的解压目录，如果配置文件没有指定rocketmq使用的文件目录，一般默认和rocketmq-all-4.4.0-bin-release这个文件夹相同的目录的，如果执行目录，需要设置相同目录

 

2、编辑并上传配置文件

    因为是三主三从异步刷盘数据模式，所以在

    rocketmq-all-4.4.0-bin-release/conf/2m-2s-async/目录设置好配置文件，如下图所示

配置文件内容这里根据实际情况添加，本人会把多有配置都放在配置文件里，其中包括namesrvAddr 这个配置选项。

    

    然后修改对应可执行文件的内存设置

    修改sh脚本jvm内存限制（根据自己实际情况），如果你有指定jdk/jre环境的话可以在这里指定路径

 

   

3、设置脚本的可执行权限

一下三个文件需要设置可执行权限

    设置权限主要是如下几个命令

chgrp rocketmq rocketmq-all-4.4.0-bin-release -R #设置文件及子文件的用户组chown rocketmq rocketmq-all-4.4.0-bin-release -R #设置可执行文件及子文件的拥有者

    设置了用户和用户组之后也可以忽略设置可执行权限

 

第二阶段升级namesrv服务

 

    如果第一阶段内容都没有问题那么我们开始执行升级namesrv服务

 

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