产生的 Oplog 为:
以上 MongoDB 可以保证 Oplog 的数据操作(DML 语句)是幂等的，但数据表操作(DDL 语句)命令无法保证，例如重复执行相同的 createIndex 命令。
Oplog 的查询
Capped collection 内文档是以插入顺序排序的，没有其他索引，但是 local.oplog.rs 是一个特殊的 capped collection，在 Wiredtiger 引擎的话，Oplog 的时间戳会作为一个特殊的元信息存储，使得 Oplog 可以以 ts 字段排序，查询 Oplog 时可以利用 ts 字段筛选。
一般来说 Secondary 同步需要经过 initial sync 和 incremental sync，initial sync 同步完成后，需拉取从同步时间点开始之后的 Oplog 进行持续重放。所以查询 Oplog 的操作一般是：
Secondary 需要不断获取 Primary 产生的 Oplog, 复制集会使用 tailable cursor 持续获取 Oplog 数据，非常类似 Unix 系统的 tail -f。这会提高效率，因为一般的 cursor 使用完毕后就会关闭，而 tailable cursor 会保存上次的 id, 并持续获取数据。
如果使用 pymongo 驱动器，则定位从某个时间点之后的 Oplog 可以这麽写：
cursor_type 使用 TAILABLE 或者 TAILABLE_AWAIT，使用后一种类型时，如果没有更多的 Oplog 数据，则这次请求会阻塞等待有 Oplog 数据或者到达等待的时间超时返回。
设置 oplog_replay 标记可以表示此次请求的类型是保存 Oplog 的 capped collection, 提供 ts 筛选参数, 进行查询优化。
获取到 Oplog 之后，就可以做数据同步或者分发到感兴趣的消费者作特殊分析，如 MongoShake 工具。
参考了文档：
Replica Set Oplog: https://docs.mongodb.com/manual/core/replica-set-oplog/ MongoDB oplog 漫谈: http://caosiyang.github.io/2016/12/24/mongodb-oplog/ MongoDB复制集原理: https://www.jb51.net/article/166148.htm
以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持七叶笔记。
