Oplog幂等性由操作语义与日志结构共同保证：update、delete类记录含完整上下文（op/ns/o2/o），重放多次结果一致；$inc等非幂等操作在oplog中被展开为最终值写入，故天然幂等。
Oplog 幂等性不是“设计目标”，而是由操作语义和日志结构共同保证的必然结果——只要不手动篡改 oplog，重放任意次数都不会导致数据不一致。
为什么 update、delete 类 oplog 记录天然幂等
Oplog 中的每条记录都包含完整上下文：操作类型（op）、目标集合（ns）、查询条件（o2）和变更内容（o）。例如一条 update oplog：
{ "ts": { "$timestamp": { "t": 1744626000, "i": 1 } }, "t": 1, "h": 12345, "v": 2, "op": "u", "ns": "test.users", "o2": { "_id": ObjectId("...") }, "o": { "$set": { "status": "active" } } }
它表达的是“把 test.users 中 _id 匹配的文档，$set status=active”。无论执行一次还是十次，最终状态都是 status: "active"。同理，op: "d" 删除操作依赖 o2 精确匹配，删掉就没了，再删无副作用。
- 插入（
op: "i"）例外：它不带o2，但 MongoDB 在初始同步或重放时会跳过已存在的 _id（靠唯一索引约束+写入前检查），实际效果仍是幂等 - 替换（
op: "u"+o含完整文档）也幂等，因为是全量覆盖 - 非幂等操作（如
$inc）在 oplog 中会被展开为“读取当前值 → 计算新值 → 写入”，所以记录的是最终值，而非增量指令
幂等性失效的典型场景与原因
真正破坏幂等性的，往往不是 oplog 本身，而是外部干预或配置错误：
- 手动向
local.oplog.rs插入/修改记录：绕过 MongoDB 内部校验，可能写入不完整o2或非法op，导致重放时行为不可控 - 使用
mongorestore恢复时未加--noIndexRestore：重建索引会改变集合元数据，后续 oplog 重放可能因索引缺失而失败或跳过 - 副本集成员间 clock skew 超过 1 秒：影响
optime排序和心跳判断，可能导致某节点反复重放同一段 oplog（虽仍幂等，但浪费资源） - 应用层误用
findAndModify配合非幂等更新器（如$push不带$each+ 去重）：oplog 记录的是最终数组状态，但如果业务逻辑依赖“第 N 次 push”，那语义上就不该靠 oplog 保证
oplog 幂等性对同步流程的实际影响
幂等性直接支撑了副本集的容错设计，但它不等于“可以随意重试”：
- Secondary 节点网络抖动断连后重连，会从断点继续拉取 oplog；若期间主节点已滚动覆盖旧 oplog，就会触发
too stale to catch up错误，此时必须走 Initial Sync —— 幂等性在这里只保“重放安全”，不保“同步可达” - Initial Sync 过程中，Secondary 一边克隆数据一边缓存新 oplog（3.4+ 版本），这部分缓存的 oplog 也是幂等重放的，避免全量同步期间的数据丢失
-
replBatcher线程消费 oplog 队列时，若某条操作失败（如磁盘满），会暂停并重试该条；因幂等，重试不会引发冲突，但需注意失败日志里是否出现InterruptedAtShutdown等掩盖真实错误的提示
真正容易被忽略的点在于：幂等性只作用于单条 oplog 记录，不保证跨多条记录的业务逻辑一致性。比如转账操作拆成两条 oplog（A 减、B 加），如果只重放其中一条，数据库状态就是中间态——这不属于 oplog 层面的问题，而应由应用层通过事务（4.0+ multi-document ACID）或补偿机制解决。
