最近公司的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才被应用。
