搭建MongoDB副本集还需要做些什么（Oplog调整）
oplog(operation log) 是一个特殊的有界集合，它维护了所有保存在数据库中的修改数据滚动记录。MongoDB在主节点上应用数据库操作之后在主节点的日志中记录操作。从节点之后会拷贝并在异步进程中应用操作。所有副本集成员包含了oplog的拷贝，local.oplog.rs集合是的副本集成员维护数据库当前状态。
为了维持副本集，所有副本集成员发送心跳包(pings)到所有其他成员。成员可以从其他任何成员导入oplog实体。
每个oplog中的操作都是幂等的。这就是说，oplog操作会产生相同的结果无论被应用多次或多次到目标数据库。
Oplog 大小
当你第一次启动一个副本集成员时，MongoDB创建了一个默认大小的oplog。
对与Uninx和Windows系统
默认的oplog大小取决于存储引擎：
| 存储引擎 | 默认oplog大小 | 下限 | 上限 |
|---|---|---|---|
| In-Memory Storage Engine | 5%物理内存 | 50mb | 50GB |
| WiredTiger Storage Engine | 5%空闲磁盘空间 | 990mb | 50GB |
| MMAPv1 Storage Engine | 5%空闲磁盘空间 | 990mb | 50GB |
对于64位OS X 系统
默认的oplog大小为物理内存或磁盘空间的192MB，依赖于存储引擎：
| 存储引擎 | 默认oplog大小 |
|---|---|
| In-Memory Storage Engine | 192MB物理内存 |
| WiredTiger Storage Engine | 192MB空闲磁盘空间 |
| MMAPv1 Storage Engine | 192MB空闲磁盘空间 |
大工作负载或许需要更大的oplog大小
如果你可以预测你的副本集工作负载类似于下面的案例。你可能需要创建一个比默认更大的oplog。相反，如果你应用主要进行读操作并且只有少量的写操作，一个更小的oplog会更高效。
下面的工作负载需要更大的oplog大小。
一次更新多个文档
oplog必须将多个更新转换成独立的操作来维持幂等性。这可能会使用到大量的oplog空间而没有相应的数据或磁盘使用。
删除量等同与插入量
如果你删除数据量等同于插入量，数据库的磁盘使用量不会显著增长，但是oplog的大小可能会很大。
大量的原地更新
如果有大量的工作是不增加文档大小的更新，那个数据库会记录大量的错做，但是不会改变数据库中的数据大小。
oplog 状态
为了查看oplog的状态，包括大小和操作的时间范围，运行rs.printReplicatinInfo(）方法。
在各种极端情况下，更新从节点的oplog可能会落后于期望的性能时间。使用从节点的db.getReplicationInfo() 和复制状态输出来评估当前复制状态并确定是有存在任何非预期的复制延迟。
