Chinaunix首页 | 论坛 | 博客
  • 博客访问: 1271272
  • 博文数量: 179
  • 博客积分: 3044
  • 博客等级: 中校
  • 技术积分: 2437
  • 用 户 组: 普通用户
  • 注册时间: 2006-03-25 15:04
文章分类

全部博文(179)

文章存档

2021年(2)

2020年(1)

2019年(5)

2018年(13)

2017年(6)

2016年(10)

2015年(11)

2014年(11)

2013年(13)

2012年(23)

2011年(25)

2010年(2)

2008年(1)

2007年(5)

2006年(51)

分类: NOSQL

2018-05-29 17:39:34


一个好好的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)


50Goplogsize怎么一下没有了?

查看监控图:

 


 



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

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

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


 

查看oplog.rs的记录:

 

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


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


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


阅读(1028) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~