如何估计Oplog的大小

转载自：http://www.mongoing.com/blog/oplog-size

 

用户问题：

最近我的一个复制集的从机出了故障，由于修复的时候耽搁了几个小时，等从机加入到复制集的时候已经超出oplog的有效窗口，只能执行resync 的动作把数据从头复制过来，很占时间。我们知道复制集的oplog size 默认是磁盘容量的5%(最小1G，最大50G）， 如果我希望增大oplog的有效窗口，我该如何选择oplog的大小呢?

(关于oplog的一些科普知识和如何对oplog扩容的操作，请参考E叔的博客： http://mongoing.com/oplog )

 

第一步：计算你的Oplog Churn

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

举例来说，下面是一台复制集中的从机的信息：

rs0:RECOVERING> db.printReplicationInfo()
configured oplog size: 36773.8849609375MB
log length start to end: 7628secs (2.12hrs)
oplog first event time: Thu Nov 27 2014 09:05:49 GMT+0800 (HKT)
oplog last event time: Thu Nov 27 2014 11:12:57 GMT+0800 (HKT)
now: Thu Nov 27 2014 14:54:45 GMT+0800 (HKT)

这个告诉我们oplog目前配置的是36G，存储了2.12小时的oplog 记录。那么oplog churn在这里大概就是17G/小时。如果你需要5个小时的Oplog，那么就需要17×5 = 85G oplog。

那么很自然的下一个问题就是如何知道我需要多长时间的Oplog？

 

第二步：确定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所需时间。道理类似于上面。

 

第三步：计算oplog大小

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

注意：修改oplog的时候一定要对所有的复制集成员做同样地修改。