MongoDB爱好者
垂直技术交流平台

如何估计Oplog的大小

用户问题:

最近我的一个复制集的从机出了故障,由于修复的时候耽搁了几个小时,等从机加入到复制集的时候已经超出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的时候一定要对所有的复制集成员做同样地修改。

赞(9)
未经允许不得转载:MongoDB中文社区 » 如何估计Oplog的大小

评论 2

评论前必须登录!

 

  1. #1

    “修改oplog的时候一定要对所有的复制集成员做同样地修改” 这个是为什么?如果oplog大小不一样有什么问题吗?

    m10年前 (2014-12-08)
  2. #2

    因为任意一个复制集成员有可能变成主节点 – 如果某个成员oplog较小,又变成了主节点,那其他的节点就有可能出现同步失败的情况。

    TJ_MongoDB10年前 (2014-12-08)