【最佳实践】巡检项：云数据库（MongoDB）oplog 保存时间

问题描述

　　oplog 在云数据库MongoDB 中作用非常重要。当Primary进行写操作的时候，会将这些写操作记录写入Primary的Oplog 中，而后Secondary会将Oplog 复制到本机并应用这些操作，从而实现Replication的功能。而回档是基于全量备份的镜像 +oplog 进行的，回档的时间取决于回放 oplog 的量，而oplog的大小是有限制的，如果容量太小，会导致oplog被冲而无法恢复指定时间点的数据，也有可能导致宕机的节点就很容易出现无法同步数据的现象。

解决方案

oplog只能保存特定数量的操作日志，通常oplog使用空间的增长速度跟系统处理写请求的速度相当。如果单次操作影响到了多个文档（比如删除了多个文档或者更新了多个文档）则oplog可能就会有多条操作日志。db.testcoll.remove() 删除了1000000个文档，那么oplog中就会有1000000条操作日志。如果存在大批量的操作，oplog有可能很快就会被写满了。

oplog 大小默认为实例容量的10%，用户可在控制台调整其大小，最小为实例容量的10%，最大为实例容量的90%。

可以在控制台->选择对应的实例->配置调整 操作调整oplog的大小

oplog调整

也可以通过调整配置来达到调整oplog的大小。

注意事项

oplog的大小设置是值得考虑的一个问题，如果oplog size过大，会浪费存储空间；如果oplog size过小，老的oplog记录很快就会被覆盖，这里需要根据业务场景来设定一个合理的值。

在调整配置过程中，可能会进行数据迁移，期间实例访问不受影响；迁移完成后会进行切换，会有秒级别闪断，请确保业务程序具备重连机制。