MONGO DB 导入数据导致的复制集解体

在一次MongoDB数据导入过程中,因OPLOG设置不当导致窗口时间急剧缩短,通过紧急在线扩容OPLOG,成功避免数据丢失,揭示MongoDB 3.6版本下OPLOG管理的重要性。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

最近公司的MONGO DB 已经上线了,存储大量应用操作中的日志,或者一些传统数据库不能,不方便存储的数据。 作为NO SQL 中的NO.1 MONGO DB 在稳定性和数据巨形吞吐是有目共睹的。 在测试库经历了 几次断电,MONGO 进程启动后,集群还是马上能开始工作,这已经说明在健壮性方面,MONGODB 集群比其他的传统数据库要 “牛的多”,当然从原理上讲也是应该的,非事务话的操作,不寻求数据某一个时间段的唯一性。 另外MONGODB  存储日志,对比Elasticsearch 也是各有优势,MONGO DB 在于他对日志操作的连续性,以及关联性,这点是Elasticsearch 所不能给的,所以重要的系统的日志,部分企业还是使用MONGO DB 而不是 Elasticsearch。

话归正传,最近比较忙,MONGO 上线,虽然性能分析器OPS已经上线了,但监控运维还是在搞的状态,并且手上还有 MYSQL MGR 系统的搭建,今天来了一个需求,要从传统的数据库中导入不到20G 的数据,这本来对MONGO DB 来说塞牙缝都不够,在测试库上,(配置不高),导出数据也就花了10分钟左右,在导入到生产数据库时,由于脑子放到了MYSQL MGR 上面,忘记了MONGO DB 这边的OPLOG 设置仅仅20G,并且我还先导入了生产非正式表,让开发先验证了数据的准确性,导入的速度非常快不到10分钟,20G 不到的数据就妥妥的存入了MONGO DB。

我忽略的就是OPLOG 设置大小与已经快速导入了20G的数据到MONGO DB,虽然我已经有所警觉,再次导入数据的时候,已经限速了,想着不会出什么事情,看了一眼oplog windows ,7 DAYS ,还长着呢。

导入的速度由于限速了,速度很慢,我偶尔看一眼 OPLOG WINDOWS ,后来降到 3 DAYS ,在后面降到 1 DAYS ,我开始注意到,OPLOG 窗口越来越小。

这里普及一个知识,什么是OPLOG,当Primary进行写操作的时候,会将这些写操作记录写入Primary的Oplog 中,而后Secondary会将Oplog 复制到本机并应用这些操作,从而实现Replication的功能。同时由于其记录了Primary上的写操作,故还能将其用作数据恢复。可以简单的将其视作Mysql中的binlog,但部分原理不一样。

如果这放到了MONGO DB 3.4 估计只有等死的份了,但选型的时我们选择了MONGO DB 3.6, 可以在线扩充 OPLOG 的容量,这点在这个时刻是可以救命的。

马上扩充OPLOG ,直接将原来的20G 改为 45G 在所有的节点上操作

这时OPLOG WINDOWS 给我的时间已经不足40分钟了。

随着调节OPLOG WINDOWS 后,OPLOG 的时间窗口在一点点的提升,情况好转了,警报解除了。

继续通过命令来观察

每刷新一次,OPLOG  first event time  和  last event time 之间的距离越来越远。至此一场危机度过。 咻

经过查询,其实张友东,早在MONGO 3.2 就提出过即时修改的方案给官方,但3.6才被应用。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值