rocketmq-4：线上rocketmq slave节点的ECS宕机恢复实记

原创；

微信公众号：千里行走；

头条技术号：实战架构；

目录

(1).问题发现与持续时间

(2).恢复操作

(3).恢复期间的数据

1.slave节点恢复数据的TPS

2.cpu-iowait

3.cpu-jumps

4.cpu-load

5.带宽升幅

(4).总结

正文

(1).问题发现与持续时间

阿里云钉钉提醒：

ECS宕机时间：2019.6.10下午2点57分

恢复时间：2019.6.11下午4点

（由于10号我请病假，所以堆积了大概一天的消息约5600万需要同步到slave；顺便也体现了一下rocketmq的优越性之消息堆积，有利码农身心健康；是否有利码农身心健康也是本人技术选型的重要依据之一，太复杂/性价比低/不必要直接毙）

持续时间：24小时

对业务影响：无，消费者是从broker-master取数据。

(2).恢复操作

执行重启命令：注意参数，指定的broker的配置文件要正确

nohup /app/3rd/apache-rocketmq/bin/mqbroker -n'rocketmq-c0-namesrv001.xxx-inc.com:9876;rocketmq-c0-namesrv002.xxx-inc.com:9876' -c /app/3rd/apache-rocketmq/conf/2m-2s-async/broker-b-s.properties> /data/xxx/logs/rocketmq/nohup-broker.out &

启动持续时间：大概5分钟左右

a.注意：

1.启动完成的标志是namesrv中挂载成功。

2.之所以需要这么长的启动时间，是因为堆积了5600万消息需要先从broker-master处同步到slave后才会挂载到namesrv。

恢复期间日志：

(3).恢复期间的数据

1.slave节点恢复数据的TPS

可以看到TPS飙升到了30W/秒（当然iowait也彪了，大概40%，见后）。

2.cpu-iowait

iowait飙升到了近40%，后续有空会升级到SSD，没有什么成本(磁盘小点儿就行)，极端情况下的可用性大幅提高。

我们zabbix设置的报警阈值是：20

3.cpu-jumps

可以看到IO中断大幅飙升，从平时的1.7K飙升到31K，是平时的18倍。

4.cpu-load

可以看到load>5，实际上要比这个高不少(zabbix实时性差)，是平时的几十倍了；这也是mq一定要用ssd的原因，提供极端情况下的健康水准。

5.带宽升幅

500Mbps+，带宽跑满1/3。

我们选在的机型：

(4).总结

1.rocketmq性能足够；

2.尽量还是使用ssd盘，不会有什么额外成本，ssd盘现在很便宜，极高的提升了极端情况下集群的健康水平；