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进行如上操,作即可完成。

  • 0
    点赞
  • 0
    评论
  • 0
    收藏
  • 一键三连
    一键三连
  • 扫一扫,分享海报

相关推荐
©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页