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

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