前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >rocketmq-4:线上rocketmq slave节点的ECS宕机恢复实记

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

作者头像
千里行走
发布2019-07-12 15:14:08
1.5K0
发布2019-07-12 15:14:08
举报
文章被收录于专栏:千里行走

原创;

微信公众号:千里行走;

头条技术号:实战架构;

目录

(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盘现在很便宜,极高的提升了极端情况下集群的健康水平;

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2019-07-06,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 千里行走 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
相关产品与服务
对象存储
对象存储(Cloud Object Storage,COS)是由腾讯云推出的无目录层次结构、无数据格式限制,可容纳海量数据且支持 HTTP/HTTPS 协议访问的分布式存储服务。腾讯云 COS 的存储桶空间无容量上限,无需分区管理,适用于 CDN 数据分发、数据万象处理或大数据计算与分析的数据湖等多种场景。
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档