Mongodb oplog window故障

一个好好的Mongodb复制集，突然报oplog window只有0.5H了，这是主从要崩问题呀。

先看主从情况：

主从状态正常

db.printReplicationInfo()

configured oplog size:   51200MB

log length start to end: 2063secs (0.57hrs)

oplog first event time:  Tue May 29 2018 10:23:37 GMT+0800 (CST)

oplog last event time:   Tue May 29 2018 10:58:00 GMT+0800 (CST)

now:                     Tue May 29 2018 10:58:00 GMT+0800 (CST)

50G的oplogsize怎么一下没有了？

查看监控图：

 

 

根据监控图来看：5月29日凌晨开始问题出现：每小时Oplog每小时的读写量从几MB慢慢上升到100G/小时，而oplog window 则从4166小时降到2小时到后面的0.5小时，到最后整个业务数据库主从不可用（只剩下主）

  Mongodb的日志却没有异常，这个到底出现了什么情况！而且还有一个很严重的问题，我的备份体系在昨晚没有备份成功，所有的备份都宕住了，这个后果有点严重。

但是从整个网络流量图（下图）又没有异常，真是摸不到头脑呀。

 

查看oplog.rs的记录：

 

也是同样的结果，记录条数从15万到几万条。从这里可以推断出oplog的记录的大小应该突然变大了，因为oplog.rs是capped类型的集合，大小是固定的，只会保存最近的操作。

看一下oplog.rs的记录，发现仅存的记录中有一条记录有1M多，那就是50G只能5W记录，基本上可以确认是业务操作引起的。

找到业务确认：存放大记录的表里数据有13条，每一条记录都超过1M，而且有一个业务原理是这样：修改本身记录的同时要去更新这个大记录，这就可以解释整个原因了，网络流量不大，因为业务操作本身的流量每次都很少，但是次数比较多，但是每次都会触发大记录的update,而Mongodb的oplog.rs会记录整个完整的数据操作，所以oplog.rs会有大量的超大记录的操作，objects被迅速缩减到几万条记录，也就是oplog window只有0.5小时，如果不处理，整个复制集会宕住，不过万幸的是：业务接到通知在早上9点左右莫名的停了这个业务，Mongodb window正在慢慢恢复！