记一次线上MongoDB宕机

Posted 2021-05-01 重庆JAVA圈

过程：

    一天早上8点小G发现监控API有延时很大，而且有不断扩大的现象。查看基础设施的告警，发现一个做了sharding的Mongo集群宕机了！！心想不应该呀，这个集群宕一台也可以用的呀。在一堆告警中发现同一sharding出现了两台挂了，无语了（3台挂了两台，我们本来也有自动重启脚本，当然这次没有生效）。当然马上让DBA启起来，然后就可以用了。但是这明显是一次重大故障，下面进行了分析。

原因：

    一功能每日夜间统计的功能对生产数据库产生了较为严重的影响。统计程序会于每日凌晨4点左右连接我们一高负载数据库，统计不是很重要的表中当天的信息，其统计方式为仅根据时间进行全量查询，但是该表只有XXX的索引（该索引5.6G）,只会用到XXX的部分索引，因此此查询操作需要扫描XXX整个索引数据，而该索引数据几乎均为冷数据，不在内存中，从而导致mongod进程在短时间内申请了6个多G的内存数据，触发频繁的内存替换，极大的加剧了IO开销，导致磁盘的利率用飙升至90%，达到了存储的性能瓶颈，存储速度的下降也会进一步的加剧内存的开销，极大的增加了数据库异常宕机的概率。当时其中一台就宕了，然后连锁反应又宕了第二台，就有了开始的现象。

解决：

从平台整体稳定性考虑，不能因为一个统计的功能而影响平台的主要实时业务，因此需要以最快的速度将这个表从数据库中迁移出去，或者改变统计方式，不再使用该表进行统计

后记：

1、线上不进行统计

2、一些重启脚本一定要有相同环境的演练