Oplog

1.简介

Oplog 是一个capped collection。Mongodb默认将其大小设置为可用disk空间的5%（默认最小为1G，最大为50G），或也可以在mongodb复制集实例初始化之前将mongo.conf中oplogSize设置为我们需要的值。当Primary进行写操作的时候，会将这些写操作记录写入Primary的Oplog 中，而后Secondary会将Oplog 复制到本机并应用这些操作，从而实现Replication的功能。同时由于其记录了Primary上的写操作，故还能将其用作数据恢复。

2.查看Oplog信息

db.getReplicatonInfo()

如果在集群中部署了Ops Manager，也可通过Ops Manager查看。

3.估计Oplog的大小

(1)计算Oplog churn

Oplog churn是单位时间内oplog的增长速度。如果是大部分写入新数据的场景是可以根据每小时写入率 x 平均文档大小计算出来的。对于更新为主的应用，则要通过测试并观察 db.printReplicationInfo() 输出的结果来得到。
Example:

主节点

rs0:PRIMARY> rs.printReplicationInfo()
configured oplog size:   990MB
log length start to end: 63002secs (17.5hrs)
oplog first event time:  Wed Dec 28 2016 16:31:09 GMT+0800 (CST)
oplog last event time:   Thu Dec 29 2016 10:01:11 GMT+0800 (CST)
now:                     Thu Dec 29 2016 10:01:16 GMT+0800 (CST)

从节点

rs0:SECONDARY> rs.printReplicationInfo()
configured oplog size:   9900MB
log length start to end: 63164secs (17.55hrs)
oplog first event time:  Wed Dec 28 2016 16:33:07 GMT+0800 (CST)
oplog last event time:   Thu Dec 29 2016 10:05:51 GMT+0800 (CST)
now:                     Thu Dec 29 2016 10:05:56 GMT+0800 (CST)

从得到了信息可以看到，目前oplog的大小是9900M，即9.66G，存储了17.55H的数据，可以估算出oplog churn的大小是0.966/17.55=0.55G,如果要10个小时的oplog，则oplg的大小应该是0.55*10=5.5。

(2)确定oplog的窗口时间

Oplog的有效窗口时间必须是下述任务所需时间的最大值：
1） Initial Sync/Resync一个从机所需时间

想象一下， 如果新加一台从机，它从2014年11月27日9点开始克隆数据库。复制完成后，再把9点以后复制过程中新进来的操作以oplog方式追加到从库上从而完成最终同步。如果克隆数据库需要12个小时，而oplog只能保存5个小时的记录，那么在晚上9点从机试图开始追加oplog的时候发现oplog只有下午4点以后的内容了！ 上午9点到下午4点7个小时的操作已经不存在，无法被同步。所以说oplog的窗口时间必须大于initial sync或者resync中复制数据库的时间。

克隆数据库所需时间比较难估计，可以使用一个样本数据库进行initial sync或者resync的测试并记录所需时间，并估算生产数据库的所需时间。
2） 恢复一个备份的数据库到从机上所需时间

另外一个类似的操作就是有时候你需要从备份恢复数据库。假设说你的备份策略是6小时一次，并且从备份恢复一个数据库的时间是2个小时，那么你的oplog的有效时间必须大于 8小时（6+2）。如果小于8小时的话，你恢复的数据库就没法追加所有在这期间在主节点上产生的oplog。 （当然，你的备份还是可以用来做一个整个复制集的恢复，如主节点）

3） 对从库进行压缩或修复所需时间

有些时候我们会把从库下线做一些维护操作，如compact或者repair。Oplog的窗口有效时间也必须大于这个compat或repair所需时间。道理类似于上面。

(3)计算oplog的大小

有了oplog churn和oplog所需窗口时间，乘一下就可以得到我们希望为oplog设置的大小。如果oplog churn是1G，上述最大值是8个小时，那我们可以选择10小时（有一点空间），oplog的大小就应该是1×10=10G。

注意：修改oplog的时候一定要对所有的复制集成员做同样地修改。因为任意一个复制集成员有可能变成主节点 – 如果某个成员oplog较小，又变成了主节点，那其他的节点就有可能出现同步失败的情况。

4.Oplog扩容

1.背景：

一个由3个节点组成的复制集。

2.主节点：

A 从节点：B,C

3.需求：

Oplog扩容，尽量少的影响业务。

4.思路：

先由从节点开始，一台一台的从复制集中剥离，修改，再回归复制集，最后操作主节点来减少业务影响时间。

5.流程：

1.先将B节点关闭，去掉–replSet启动参数,更换启动端口–port,将节点以单机模式启动。

mongod --port 37017 --dbpath /home/mongo/rs/rs1/db/  --logpath /home/mongo/rs/rs1/mongo.log

然后备份其现有的oplog：

mongodump –db local –collection ‘oplog.rs’ –port 37017

2.进入mongo，将现在的oplog中最新的位置复制到tmp表（local数据库）中：

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

3.确认tmp中的数据：

db.temp.find()

4.删除原有的oplog：

db.oplog.rs.drop()

5.建立新的oplog（capped），下例为2G大小，可根据需求修改：

db.createCollection('oplog.rs',{capped:true,size:2*1024*1024*1024})

6.将tmp中的数据存储到新的oplog中，并验证:

db.oplog.rs.save(db.temp.find().next())
db.oplog.rs.find()

6.关闭B节点，并恢复原有config配置，并在config中设置oplogSize为你之前设置的大小，并启动。
7.继续对C节点进行如上操作，C节点完成后最后对主节点A进行如上操，作即可完成。