mysql binlog oplog_mongodb 学习之oplog

背景：

原来一个同事问我主从mongodb数据库为什么数据差距很大,我让他察看一下两边有啥不一样，发现

主的local库有13G从却很小，进入local之后du发现有一个collection前缀的文件有13g，说明是local数据库中一个集合太大了，推测是oplog太大了，oplog是类似于mysql的binlog oracle的archivelog

当Primary进行写操作的时候，会将这些写操作记录写入Primary的Oplog中，而后Secondary会将Oplog复制到本机并应用这些操作，从而实现Replication的功能。同时由于其记录了Primary上的写操作，故还能将其用作数据恢复。可以简单的将其视作Mysql中的binlog。

为了进一步确认，进入mongodb之后通过

show dbs

use local

show collections

看到现有的集合

然后

db.getReplicationInfo()

rs.printReplicationInfo()

了解一下复制信息以及oplog大小与使用情况

为进一步确认相应的文件是否为oplog

db.printCollectionStats()

根据展示出来的结果只需要知道两条信息：

"ns" : "local.oplog.$main",

"uri" : "statistics:table:local/collection-2-1716662444632575459"

就可以确认oplog集合的相应文件，oplog如果太大可以清理和修改大小。

MongoDB oplog是一个capped collection，创建capped collection时，createCollection可以设置size(最大字节数)和max(最大文档数)的参数，当这个集合的『总大小超过size』或者『总文档数超过max』时，在新插入文档时就会自动删除一些集合内最先插入的文档，相当于一片环形的存储空间。

oplog(local.oplog.rs集合)默认情况下配置为可用磁盘空间的5%，当oplog写满时，就会开始删除最先写入的oplog，一次正常的insert操作包含如下步骤：将文档写入指定的集合

将写入操作记录到oplog

如果oplog满了，删除最先写入的oplog

优化策略

MongoDB 3.2为了提升写入性能，使用wiredtiger引擎时，针对local.oplog.rs这个集合的删除策略进行了优化，主要改进：将删除动作从用户的写入路径移除，放到后台线程执行

批量删除，并不是oplog一满就立马触发删除，而是一次删除一批

实施方案

monogd启动时，会根据o