1. 基本概念
oplog使用固定大小集合记录了数据库中所有修改操作的操作日志(新增、修改和删除，无查询)，mongodb收到修改请求后，先在主节点（primary）执行请求，再把操作日志保存到oplog表中，其他从节点（secondary）到主节点拉取oplog并在异步进程中应用这些操作，从而达到主从数据的一致性。复制组内的所有节点都会保存一份oplog(集合名local.oplog.rs)，这让他们可以保持同样的数据库状态。
为了提高同步效率，所有复制组成员都会向其他成员发送保活报文(pings)，任意从节点可以从其他成员节点同步oplog（即可以从主节点同步，也可以从从节点同步）。oplog中的操作都是幂等的，即oplog中的某个操作日志在目标数据库中应用一次或者多次，其结果都是一样的。
主从同步示意图如下(客户端写数据到主节点，从节点从主节点同步oplog并应用到本节点)：
2. oplog 的默认储存大小
当你首次启动复制组节点时，在你未指定oplog大小时，mongodb会使用默认大小来创建oplog。
对于unix和windows系统来说，默认大小和存储引擎的对应关系如下：
| 存储引擎类型 | oplog大小 | 下限 | 上限 |
| 内存 | 物理内存的5% | 50mb | 50gb |
| wiredtiger | 空闲磁盘的5% | 990mb | 50gb |
(注意，最新4.4版本的mongodb移除了mmap类型存储引擎的支持。)
对于64位maxos系统来说，参照使用的存储引擎类型，该默认大小是192mb（物理内存或者磁盘空间），如下：
| 存储引擎类型 | oplog大小 |
| 内存 | 192mb物理内存 |
| wiredtiger | 192mb的磁盘空间 |
大部分情况下，oplog的默认大小是足够的。举个例子，如果5%的磁盘空间存储了最近24小时的操作日志，此时如果某个从节点的日志同步时间差超过24小时时，从节点将停止同步oplog，并将自身的状态从[secondery]切换到[stale]。当然，在实际的运行环境中，大部分复制组成员的负载会低一些，他们的oplog中也会持有更长时间段的日志。
3. 可能需要更大oplog的工作负载
如果你预测到你的复制组的工作负载属于以下的模式，你需要创建比默认值更大一些的oplog。相反的，如果你的应用大部分情况下是读操作，只有小部分的写操作，那么更小一些的oplog也是满足需要的。
下面的工作负载可能需要更大一些的oplog
单次操作会更新多条记录
为了满足oplog的幂等性，单次操作更新多条记录时，mongodb会记录多条操作日志到oplog中，这种场景就需要使用大量的oplog的空间，虽然此时数据大小或者磁盘大小并没有相应的增加那么多。
删除操作和插入操作一样多时
如果你的删除操作请求量和插入操作的请求量大致相当时，数据库在磁盘空间消耗方面不会有明显增长，但是操作日志的大小会非常巨大。
显著数量的原文档更新
如果工作负载的大部分操作都是原文档更新，此时虽然不会增加数据库中文档的数量，但是数据库需要记录大量的操作日志。
4. oplog状态
如果要查看oplog的状态，包含记录条数和时间范围，可以使用"rs.printreplicationinfo() "命令，如下：
|
1 2 3 4 5 6 |
mongodb enterprise repa: primary > rs.printreplicationinfo() configured oplog size : 1024mb // oplog大小是1024mb log length start to end : 867353secs (240.93hrs) // 第一条和最后一条日志的时间差是240.93小时 oplog first event time : wed jul 07 2021 20:24:57 gmt+0800 oplog last event time : sat jul 17 2021 21:20:50 gmt+0800 now: sat jul 17 2021 21:20:56 gmt+0800 |
5. oplog格式
从前面知道oplog是存储在数据库local中，表名为[oplog.rs]，通过查询命令看一下oplog的数据格式：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
db.oplog.rs.find({ "ns" : "test.users" }).limit(1) // ns字段指明查询对数据库test中users表的操作日志 { "ts" : timestamp (1625660877, 2), // 日志的操作时间戳，第一个数字是时间戳，单位秒，第二个数字是当前秒的第2个操作 "t" : numberlong(2), "h" : numberlong( "5521980394145765083" ), "v" : 2, "op" : "i" , // i表示 insert ，u表示 update ,d表示 delete ，c 表示的是数据库的命令，比如建表,n表示noop,即空操作 "ns" : "test.users" , // 命名空间，即数据库和集合名称 "ui" : uuid( "edabbd93-76eb-42be-b54a-cdc29eb1f267" ), // 连接到mongodb的客户端会话id "wall" : isodate( "2021-07-07t12:27:57.689z" ), // 操作执行时间，utc时间 "o" : { // 操作的内容，对于不同的op类型，其格式不尽相同 "_id" : objectid( "60e59dcd46db1fb4605f8b18" ), "name" : "1" } } |
6. cud操作和oplog的对应关系
前面分析oplog日志格式的时候，查看了一条insert操作对应的日志，就不再赘述，下面再看下delete和update对应的日志格式(find不会产生oplog)。
delete操作
首先插入三条记录：
|
1 |
mongodb enterprise repa: primary > use testswitched to db testmongodb enterprise repa: primary > db.users. insert ({ "name" : "张三" , "age" :numberint(10), "sex" : "男" })writeresult({ "ninserted" : 1 })mongodb enterprise repa: primary > db.users. insert ({ "name" : "李四" , "age" :numberint(11), "sex" : "男" })writeresult({ "ninserted" : 1 })mongodb enterprise repa: primary > db.users. insert ({ "name" : "王五" , "age" :numberint(12), "sex" : "男" })writeresult({ "ninserted" : 1 })mongodb enterprise repa: primary > db.users.find(){ "_id" : objectid( "60f2e11b0d98dc3b374199de" ), "name" : "张三" , "age" : 10, "sex" : "男" }{ "_id" : objectid( "60f2e11e0d98dc3b374199df" ), "name" : "李四" , "age" : 11, "sex" : "男" }{ "_id" : objectid( "60f2e11e0d98dc3b374199e0" ), "name" : "王五" , "age" : 12, "sex" : "男" } |
执行delete操作，匹配条件是{"sex":"男"}，即删除所有性别为男的记录：
|
1 2 3 4 |
mongodb enterprise repa: primary > db.users.remove({ "sex" : "男" }) writeresult({ "nremoved" : 3 }) mongodb enterprise repa: primary > db.users.find() mongodb enterprise repa: primary > |
可以看到，一条删除命令删除了三条记录，对应的oplog是什么呢，来，查一下：
|
1 2 3 4 5 6 7 |
mongodb enterprise repa: primary > use local switched to db local mongodb enterprise repa: primary > db.oplog.rs.find({ "ns" : "test.users" , "op" : "d" , "wall" :{ "$gt" :isodate( "2021-07-17t13:50:57.689z" )}}) { "ts" : timestamp (1626530154, 1), "t" : numberlong(2), "h" : numberlong( "5834731856459959506" ), "v" : 2, "op" : "d" , "ns" : "test.users" , "ui" : uuid( "edabbd93-76eb-42be-b54a-cdc29eb1f267" ), "wall" : isodate( "2021-07-17t13:55:54.424z" ), "o" : { "_id" : objectid( "60f2e11b0d98dc3b374199de" ) } } { "ts" : timestamp (1626530154, 2), "t" : numberlong(2), "h" : numberlong( "-2164276082472824844" ), "v" : 2, "op" : "d" , "ns" : "test.users" , "ui" : uuid( "edabbd93-76eb-42be-b54a-cdc29eb1f267" ), "wall" : isodate( "2021-07-17t13:55:54.424z" ), "o" : { "_id" : objectid( "60f2e11e0d98dc3b374199df" ) } } { "ts" : timestamp (1626530154, 3), "t" : numberlong(2), "h" : numberlong( "3834858247238363179" ), "v" : 2, "op" : "d" , "ns" : "test.users" , "ui" : uuid( "edabbd93-76eb-42be-b54a-cdc29eb1f267" ), "wall" : isodate( "2021-07-17t13:55:54.424z" ), "o" : { "_id" : objectid( "60f2e11e0d98dc3b374199e0" ) } } mongodb enterprise repa: primary > |
从上可以看到，一条删除命令，在oplog中记录了三条日志，下面分析其中的一条：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
{ "ts" : timestamp (1626530154, 1), "t" : numberlong(2), "h" : numberlong( "5834731856459959506" ), "v" : 2, "op" : "d" , // 删除操作 "ns" : "test.users" , // 数据库是test，集合是users "ui" : uuid( "edabbd93-76eb-42be-b54a-cdc29eb1f267" ), "wall" : isodate( "2021-07-17t13:55:54.424z" ), "o" : { // 待删除记录的_id "_id" : objectid( "60f2e11b0d98dc3b374199de" ) } } |
从上面日志分析可以得到结论：
用户的一次删除请求，如果删除了n条记录，那么oplog中将记录n条日志，日志中会记录待删除记录的[_id]字段，与用户的删除请求的参数无关。
update操作
下面再看下更新操作对应的oplog的日志数量和格式。
首先插入三条记录：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
mongodb enterprise repa: primary > use test switched to db test mongodb enterprise repa: primary > mongodb enterprise repa: primary > db.users. insert ({ "name" : "张三" , "age" :numberint(10), "sex" : "男" }) writeresult({ "ninserted" : 1 }) mongodb enterprise repa: primary > db.users. insert ({ "name" : "李四" , "age" :numberint(11), "sex" : "男" }) writeresult({ "ninserted" : 1 }) mongodb enterprise repa: primary > db.users. insert ({ "name" : "王五" , "age" :numberint(12), "sex" : "男" }) writeresult({ "ninserted" : 1 }) mongodb enterprise repa: primary > db.users.find() { "_id" : objectid( "60f2e2db0d98dc3b374199e1" ), "name" : "张三" , "age" : 10, "sex" : "男" } { "_id" : objectid( "60f2e2db0d98dc3b374199e2" ), "name" : "李四" , "age" : 11, "sex" : "男" } { "_id" : objectid( "60f2e2dc0d98dc3b374199e3" ), "name" : "王五" , "age" : 12, "sex" : "男" } |
再执行更新操作：
|
1 2 3 4 5 6 |
mongodb enterprise repa: primary > db.users. update ({ "sex" : "男" }, { "$inc" :{ "age" :numberint(1)}}, false , true ) writeresult({ "nmatched" : 3, "nupserted" : 0, "nmodified" : 3 }) mongodb enterprise repa: primary > db.users.find() { "_id" : objectid( "60f2e2db0d98dc3b374199e1" ), "name" : "张三" , "age" : 11, "sex" : "男" } { "_id" : objectid( "60f2e2db0d98dc3b374199e2" ), "name" : "李四" , "age" : 12, "sex" : "男" } { "_id" : objectid( "60f2e2dc0d98dc3b374199e3" ), "name" : "王五" , "age" : 13, "sex" : "男" } |
从返回结果可以看到，更新操作执行成功，并更新了三条记录，下面看下oplog的日志：
|
1 2 3 4 5 6 |
mongodb enterprise repa: primary > use local switched to db local mongodb enterprise repa: primary > db.oplog.rs.find({ "ns" : "test.users" , "op" : "u" , "wall" :{ "$gt" :isodate( "2021-07-17t13:50:57.689z" )}}) { "ts" : timestamp (1626530575, 1), "t" : numberlong(2), "h" : numberlong( "-6359278368726841648" ), "v" : 2, "op" : "u" , "ns" : "test.users" , "ui" : uuid( "edabbd93-76eb-42be-b54a-cdc29eb1f267" ), "o2" : { "_id" : objectid( "60f2e2db0d98dc3b374199e1" ) }, "wall" : isodate( "2021-07-17t14:02:55.319z" ), "o" : { "$v" : 1, "$set" : { "age" : 11 } } } { "ts" : timestamp (1626530575, 2), "t" : numberlong(2), "h" : numberlong( "-4351658862590633053" ), "v" : 2, "op" : "u" , "ns" : "test.users" , "ui" : uuid( "edabbd93-76eb-42be-b54a-cdc29eb1f267" ), "o2" : { "_id" : objectid( "60f2e2db0d98dc3b374199e2" ) }, "wall" : isodate( "2021-07-17t14:02:55.319z" ), "o" : { "$v" : 1, "$set" : { "age" : 12 } } } { "ts" : timestamp (1626530575, 3), "t" : numberlong(2), "h" : numberlong( "5911110003695351597" ), "v" : 2, "op" : "u" , "ns" : "test.users" , "ui" : uuid( "edabbd93-76eb-42be-b54a-cdc29eb1f267" ), "o2" : { "_id" : objectid( "60f2e2dc0d98dc3b374199e3" ) }, "wall" : isodate( "2021-07-17t14:02:55.319z" ), "o" : { "$v" : 1, "$set" : { "age" : 13 } } } |
和delete类似，update操作也是产生了三条日志，选第一条分析：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
{ "ts" : timestamp (1626530575, 1), "t" : numberlong(2), "h" : numberlong( "-6359278368726841648" ), "v" : 2, "op" : "u" , // 更新操作 "ns" : "test.users" , // 数据库test，集合是users "ui" : uuid( "edabbd93-76eb-42be-b54a-cdc29eb1f267" ), "o2" : { // 更新操作的查询条件，使用的记录的_id "_id" : objectid( "60f2e2db0d98dc3b374199e1" ) }, "wall" : isodate( "2021-07-17t14:02:55.319z" ), "o" : { // 更新操作的更新内容，原始的inc操作符转变为 set 操作符，可以满足幂等性 "$v" : 1, "$set" : { "age" : 11 } } } |
从上面日志分析可以得到结论：
用户的一次更新请求，如果更新了n条记录，那么oplog中将记录n条日志，日志中记录待更新记录的[_id]字段为查询条件，更新操作使用的是set操作符，并不是用户的更新操作符。
小结
从上面的delete和update操作对应的oplog日志分析可以看出，oplog记录的不是用户的原始命令，而是对应的逻辑命令，通过这种方式可以满足oplog的幂等性，但是也会衍生出可能产生大量oplog记录的问题，需要用户根据业务模型的需要，来选择合适的oplog大小。
https://github测试数据/tomliugen
总结
到此这篇关于mongodb中oplog介绍和格式详析的文章就介绍到这了,更多相关mongodb oplog和格式内容请搜索服务器之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持服务器之家！
原文链接：https://HdhCmsTestcnblogs测试数据/xinghebuluo/p/15003040.html
查看更多关于mongodb中oplog介绍和格式详析的详细内容...