记一次counterservice 故障处理及恢复的时间线

梳理一个timeline

预估20亿，单端口阀值约5亿和业务沟通现在总17亿，出现个别端口达到容量瓶颈，出现滚表现象

1. 预计7：17 收到11546，11547 报警。 磁盘报警10.75.22.238：/data1 = 100.00% ， 磁盘满发现是11547 dump文件导致实例crash

• 临时删除11547 dump文件
• 尝试启动 11546 实例，失败原因aof损坏，修复aof文件失败
• 8:26  进行切主：查找从库，dsp，dpadmin 均特别卡
• 9:00 变更完成主从但是由于dpamdin问题并未上线，但以周知相关业务负责同学切主库域名
• 10:35变更115456，11547主库域名

2. 11：40 业务反馈一个端口数据为空，联系同事一起分析处理

3. 滚表数据落地磁盘，和业务沟通后用rdb恢复，损失小部分数据

4. 需要用统一的rdb文件数据传输，然后域名操作不方便

5. 13:12 11547 恢复

6. 14:25 反馈11561 端口 和11547 端口

7. 选用一个新主 将table num 调整到4 ，然后其他从库以新主的rdb 为主恢复

8. 15：18 左右恢复

####总结后续改善建议，并落地实施

1. 2个table，使用率85%，滚表dump数据，计算方式修正报警
2. 添加不再dump机制
3. 统计所有的2个table的counterservice实例，并确定是不是需要滚表； 临时处理解决方式：滚动率调高—》或者扩容 ，升级

转载于:https://my.oschina.net/tingting1127723365/blog/846445