原创；
微信公众号：千里行走；
头条技术号：实战架构；
目录
(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盘现在很便宜，极高的提升了极端情况下集群的健康水平；
