一、 正常运行中集群状态（双机双主）以及宕机状态
准备三台机器192.168.213.145/128/129；192.168.213.129为宕机恢复集群所用机器；
双主集群：
192.168.213.145:30011
192.168.213.128:30011
正常运行状态：
cd ~/rocketmq4.1/bin/
sh mqadmin clusterList -n 192.168.213.145:30011 查看集群节点信息
sh mqadmin topicList -n 192.168.213.145:30011 查看Topic信息
1.png
sh mqadmin statsAll -n 192.168.213.145:30011 查看24小时内每秒的消息吞吐量，以及消息生产消费总量
2.png
宕机时状态：
在broker-a主机192.168.213.145上进行集群查询，状态异常；
3.png
二、 部署新的RocketMQ节点（namesrv和broker节点）
RocketMQ版本以及配置文件保持和原来的一致（这里以RocketMQ4.1.0为例）
旧配置文件
mqnamesrv.properties
listenPort=30011
broker-a.properties
brokerClusterName=TEST_Cluster
brokerName=broker-a
brokerId=0
brokerRole=ASYNC_MASTER
flushDiskType=ASYNC_FLUSH
namesrvAddr=192.168.213.145:30011;192.168.213.128:30011
brokerIP1=192.168.213.145
autoCreateTopicEnable=false
autoCreateSubscriptionGroup=false
listenPort=10911
broker-b.properties
brokerClusterName=TEST_Cluster
brokerName=broker-b
brokerId=0
brokerRole=ASYNC_MASTER
flushDiskType=ASYNC_FLUSH
namesrvAddr=192.168.213.145:30011;192.168.213.128:30011
brokerIP1=192.168.213.128
autoCreateTopicEnable=false
autoCreateSubscriptionGroup=false
listenPort=10911
假如broker-b所在机器宕机，新的broker-b配置文件broker-b.properties
broker-b.properties
brokerClusterName=TEST_Cluster
brokerName=broker-b
brokerId=0
brokerRole=ASYNC_MASTER
flushDiskType=ASYNC_FLUSH
namesrvAddr=192.168.213.145:30011;192.168.213.129:30011
brokerIP1=192.168.213.129
autoCreateTopicEnable=false
autoCreateSubscriptionGroup=false
listenPort=10911
最终的broker-a配置文件broker-a.properties
broker-a.properties
brokerClusterName=TEST_Cluster
brokerName=broker-a
brokerId=0
brokerRole=ASYNC_MASTER
flushDiskType=ASYNC_FLUSH
namesrvAddr=192.168.213.145:30011;192.168.213.129:30011
brokerIP1=192.168.213.145
autoCreateTopicEnable=false
autoCreateSubscriptionGroup=false
listenPort=10911
三、 数据迁移
宕机节点数据迁移，进行集群恢复
同步宕机机器上数据文件（或者磁盘挂载）至新机器：
在宕机机器(192.168.213.128)上分别执行以下同步命令：
rsync -avP ~/ rocketmq4.1/logs docker@192.168.213.129:/home/docker/data/
rsync -avP ~/store docker@192.168.213.129:/home/docker/data/
image.png
在192.168.213.129上创建软链指向拷贝而来的数据目录：
image.png
注意：
由于从宕机机器同步而来的store目录下存在abort文件（由于异常关闭而未来得及删除的文件），所以当启动新节点的时候会有一个校验数据的过程。
image.png
注意V4.1.0和V3.5.8(以某项目152.14/15为例)在此步骤的区别：
在宕机机器上先后执行如下命令：
rsync -avP ~/ rocketmq/logs docker@192.168.213.129:/home/docker/data/
rsync -avP ~/rocketmq/store docker@192.168.213.129:/home/docker/data/
在新节点机器上创建数据指向软链命令：
cd ~/rocketmq/
ln –s ~/data/store store
ln –s ~/data/logs logs
2、丢弃宕机节点数据，进行集群恢复
直接进入下一步，启动提前准备好的新节点。
四、 启动新节点，检查集群状态
在192.168.213.129上rocketmq的bin目录下执行以下命令启动新的节点：
nohup sh mqnamesrv -c ../conf/mqnamesrv.properties &
image.png
nohup sh mqbroker -c ../conf/2m-noslave/broker-b.properties &
image.png
在192.168.213.129上执行命令，出现如图为正常；
sh mqadmin clusterList -n 192.168.213.129:30011
image.png
sh mqadmin topicList -n 192.168.213.129:30011
image.png
在192.168.213.145上执行命令，出现下图为正常；
sh mqadmin clusterList -n 192.168.213.145:30011
image.png
宕机域名切换至新加入集群节点所在机器IP192.168.213.129，逐个重启旧的未宕机节点192.168.213.145
sh mqshutdown broker
sh mqshutdown namesrv
image.png
image.png
修改未宕机节点所在机器192.168.213.145上rocketmq的配置文件
旧环境配置文件：
image.png
把上图中红色框线部分修改为新的namesrv服务地址，如下图：
image.png
重新启动旧的未宕机节点192.168.213.145
nohup sh mqnamesrv -c ../conf/mqnamesrv.properties &
image.png
image.png
image.png
image.png
检查集群状态，以及运行情况：
在192.168.213.145：执行命令sh mqadmin clusterList -n 192.168.213.145:30011
sh mqadmin statsAll -n 192.168.213.145:30011
image.png
在192.168.213.129：执行命令sh mqadmin clusterList -n 192.168.213.129:30011
sh mqadmin statsAll -n 192.168.213.129:30011
image.png
如上图，集群状态恢复正常。
网友评论