背景：

原来一个同事问我主从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启动时，会根据oplog的最大字节数将整个集合分为10-100个Stone(可以理解为oplog的一段数据，包含多个文档，Stone的具体个数oplogSizeMB的配置相关)。WiredTigerRecordStore::OplogStones::OplogStones(OperationContext* txn, WiredTigerRecordStore* rs)

: _rs(rs) {

//...

unsigned long long maxSize = rs->cappedMaxSize();

const unsigned long long kMinStonesToKeep = 10ULL;

const unsigned long long kMaxStonesToKeep = 100ULL;

unsigned long long numStones = maxSize / BSONObjMaxInternalSize;

_numStonesToKeep = std::min(kMaxStonesToKeep, std::max(kMinStonesToKeep, numStones));

_minBytesPerStone = maxSize / _numStonesToKeep;

// ...

}

其中_numStonesToKeep为oplog应该保持的Stone个数，而_minBytesPerStone代表每个Stone的最小字节数。

接下来，会根据oplog当前的大小以及_minBytesPerStone来估算下，当前的oplog大致包含的Stone数量，并通过采样的方式来获取每个Stone的起始位置(不能保证每个Stone的大小跟预期完全一样)，然后将所有的Stone按顺序存储到一个队列中。

mongod在服务写请求的过程中，每次都会记录下新产生oplog的大小，当新产生的oplog的总量超过_minBytesPerStones时，就会产生一个新的Stone加入到队列中。void WiredTigerRecordStore::OplogStones::createNewStoneIfNeeded(RecordId lastRecord) {

if (_currentBytes.load() < _minBytesPerStone) {

// Must have raced to create a new stone, someone else already triggered it.

return;

}

// ...

OplogStones::Stone stone = {_currentRecords.swap(0), _currentBytes.swap(0), lastRecord};

_stones.push_back(stone);

_pokeReclaimThreadIfNeeded(); // 唤醒后台回收oplog空间的线程

}

当队列中的Stone数量超过_numStonesToKeep，后台线程就会删除最老的Stone里的数据，来回收oplog的存储空间。

修改mongodb oplog size

oplog简介：

oplog：operations log的简写，存储在一个特殊的数据库中(local)，oplog就存储在其中的oplog.$main集合里面，这个集合是一个固定集合，新操作会自动替换旧的操作，以保证oplog不会超过预设的大小，其中的每个文档都代表主节点上执行的一个操作，oplog会包含所有对数据有修改的的操作(查询操作不会记录)，默认下，oplog大小会占用64位的实例5%的可用磁盘空间。

mongo复制的过程：主节点应用业务操作修改到数据库中，然后记录这些操作到oplog中，从节点复制这些oplog，然后应用这些修改。ps：这些操作是异步的。如果从节点的操作已经被主节点落下很远，oplog日志在从节点还没执行完，oplog可能已经轮滚一圈了，从节点跟不上同步，复制就会停下，从节点需要重新做完整的同步，为了避免此种情况，尽量保证主节点的oplog足够大，能够存放相当长时间的操作记录。

查询oplog的大小及保存的操作记录持续的时长

repltest:PRIMARY> db.printReplicationInfo()

configured oplog size:   1024MB

log length start to end: 3705secs (1.03hrs)

oplog first event time:  Thu Oct 10 2013 11:13:29 GMT+0800 (CST)

oplog last event time:   Thu Oct 10 2013 12:15:14 GMT+0800 (CST)

now:                     Fri Oct 11 2013 16:33:42 GMT+0800 (CST)

查询从节点的数据源列表，其中有数据滞后的时间

repltest:PRIMARY> db.printSlaveReplicationInfo()

source:   192.168.1.101:37017

syncedTo: Fri Oct 11 2013 16:38:16 GMT+0800 (CST)

= 1 secs ago (0hrs)

source:   192.168.1.100:37017

no replication info, yet.  State: ARBITER

so,修改oplog的大小：(下面介绍两种方式)

方式一:

The oplog exists internally as a capped collection, so you cannot modify its size in the course of normal operations.另：改变oplog大小，需要在每个节点上执行维护模式。(官方推荐)

步骤：

1:重启一个实例以单机模式，

通常再关闭server之前，使用rs.stepDown() 强制primary成为secondary

2:重新创建一个新大小，

其中包含旧的oplgo的入口条目的oplog

3:重启mongod作为replica set的成员

操作步骤：

1>: Restart a Secondary in Standalone Mode on a Different Port

关闭mongod实例：

repset:PRIMARY> use admin

repset:PRIMARY> db.shutdownServer()

重启mongod实例以单机模式，修改端口，并不要加--replSet参数

＃vim /etc/mongo.conf

dbpath=/var/lib/mongodb

logpath=/var/log/mongodb/mongo.log

pidfilepath=/var/run/mongo.pid

directoryperdb=true

logappend=true

#replSet=repset

bind_ip=192.168.1.100,127.0.0.1

port=37017

oplogSize=2000

fork=true＃ mongod -f /etc/mongo.conf

备份oplog＃ mongodump --db local --collection 'oplog.rs' --port 37017

2>: Recreate the Oplog with a New Size and a Seed Entry

保存oplog的最新的时间点

> use local

> db.temp.save( db.oplog.rs.find( { }, { ts: 1, h: 1 } ).sort( {$natural : -1} ).limit(1).next() )

> db.temp.find()

删除旧的oplog

> db.oplog.rs.drop()

3> :Create a New Oplog

创建一个新的Oplog，大小为2G

> db.runCommand( { create: "oplog.rs", capped: true, size: (2 * 1024 * 1024 * 1024) } )

插入前面保存的旧的oplog的时间点的记录

> db.oplog.rs.save( db.temp.findOne() )

> db.oplog.rs.find()

4>:Restart the Member：

关闭单机实例：

> use admin

> db.shutdownServer()

修改回配置＃ vim /etc/mongo.conf

dbpath=/var/lib/mongodb

logpath=/var/log/mongodb/mongo.log

pidfilepath=/var/run/mongo.pid

directoryperdb=true

logappend=true

replSet=repset

bind_ip=192.168.1.100,127.0.0.1

port=37017

oplogSize=2000

fork=true

启动mongod

＃ mongod -f /etc/mongo.conf

重复上述步骤到所有需要更改的节点。

方式二：

步骤：

1:停掉所有replca set节点.

2:主节点删除local库下的文件，从节点删除数据目录下所有文件.

3:修改所有节点配置文件.

4:重启所有节点.

5:重新配置replca set，从节点会重新同步所有数据(initial sync).

ps：此法好处是简单，但需要停掉服务，且如果数据量很大，初始同步的成本较高

1>:关闭mongod实例(所有节点)

> use admin

> db.shutdownServer()

2>:删除local数据库下的所有文件(PRIMARY节点)

# rm -rf /var/lib/mongodb/local/*

删除mongo数据目录(其他节点上操作，可不要删错哦，建议所有rm操作先mv，待无问题时候再删除)# rm -rf /var/lib/mongodb/*

3> 修改所有节点配置文件(oplogsize)

＃ vim /etc/mongo.conf

dbpath=/var/lib/mongodb

logpath=/var/log/mongodb/mongo.log

pidfilepath=/var/run/mongo.pid

directoryperdb=true

logappend=true

replSet=repset

bind_ip=192.168.1.100,127.0.0.1

port=37017

oplogSize=2000

fork=true

4> 重启所有节点mongod

> mongod -f /etc/mongo.conf