MongoDB 4.4 Oplog终于改为MySQL Binlog机制

Oplog注意事项  盖子集合(Capped Collections),4.4版本以前的工做机制相似MySQL的Redo log,循环覆盖写。mongodb


Oplog.png


工做原理:bash

1)存1-N增删改记录,写满了自动覆盖最旧的文档,循环写,相似Redo log。app

2)Secondary在本地找到Oplog同步复制的点为27,发送请求告知Primary从序号28开始同步数据ide

3)Primary在本地搜索到28后,发送以后的数据给Secondary,若是未搜索到,返回请求没有此记录。
4)获得Primary没有该记录后,Secondary会执行initial sync初始化同步,先删除本地全部数据,拷贝Primary全量数据和在这之间有变动的增量数据。server


场景:
blog

假如你的一台Secondary挂了,Oplog又设置的太小,而且数据增加量又很快,Oplog此时被覆盖重写,那么只能进行initial sync全量同步。虽然在3.6版本里能够动态调整Oplog大小,但你没法准确估算Oplog啥时被覆盖重写。文档


在4.4版本里,Oplog能够像binlog同样,你能够根据本身的维护状况,自定义保存多久时间。get


新的参数--oplogMinRetentionHours,单位小时。--oplogMinRetentionHours=24,表明保留24小时的oplog。cmd


也能够动态修改,命令以下:同步

db.adminCommand({ "replSetResizeOplog" : 1,   "minRetentionHours" : 24 })


查看:

db.getSiblingDB("admin").serverStatus().oplogTruncation.oplogMinRetentionHours


参考文献:

https://docs.mongodb.com/manual/reference/command/replSetResizeOplog/#dbcmd.replSetResizeOplog

本站公众号
   欢迎关注本站公众号,获取更多信息