i、u、d 分别对应 insert、update、delete 操作：i 的 o 是完整文档，u 的 o 是更新器且需结合原文档计算，d 的 o 是删除条件；oplog 不提供快照，无事务边界，格式随版本变化，云服务常限制访问。

Oplog 里的 i、u、d 分别对应什么操作

它们是 MongoDB 副本集 oplog（operations log）中记录变更的最简操作类型标识，不是命令也不是状态，而是服务端写入 oplog 时自动打上的动作标签：

• i：insert，表示一条新文档被插入到集合中；oplog 条目里 o 字段是完整文档内容
• u：update，表示已有文档被修改；o 是更新器（如 {$set: {...}}），o2 是匹配条件（通常是 {_id: ...}）
• d：delete，表示文档被删除；o 是删除条件（如 {_id: ObjectId("...")}），没有 o2

注意：u 和 d 都不记录原始文档快照，只记“怎么改”或“删谁”，这是做增量同步时容易漏掉数据的关键点。

为什么不能直接靠 o 字段还原出变更后的文档

因为 o 在不同操作类型下语义完全不同，硬解析会出错：

• i 的 o 是完整文档 → 可直接用
• u 的 o 是更新操作符（如 {$set: {a: 1}, $inc: {b: 2}}）→ 必须结合原文档计算结果
• d 的 o 是查询条件 → 不含任何字段值，无法还原被删内容

常见错误：写监听脚本时统一取 o 当作新文档，结果 u 和 d 场景下拿到的是垃圾数据。真实场景中，要做字段级变更同步，必须搭配上游数据库的读取能力（比如用 find 查原文档再 apply update）。

从 oplog 里安全读取变更的几个硬约束

oplog 不是通用日志接口，它设计目标是副本集内部复制，对外暴露有严格限制：

• oplog 是 capped collection，空间固定，旧条目会被覆盖 → 不能长期离线消费，必须保持游标活跃
• oplog 没有事务边界，多文档更新（如 updateMany）会拆成多个 u 条目，但彼此无顺序标记 → 无法保证原子性还原
• 4.2+ 版本开始支持 applyOps 命令回放，但仅限 admin 数据库且需权限；普通应用不可直接调用
• 使用 getMore 拉取 oplog 时，若游标超时（默认 10 分钟），下次必须从最新位置重连，中间断档不可恢复

也就是说，想靠 tail oplog 做准实时同步，得自己处理断连、去重、幂等、反向查原值——这些都不是 MongoDB 帮你兜底的事。

实际用 oplog 做同步时最容易忽略的兼容性坑

oplog 格式随版本演进过多次，低版本驱动或自定义解析器常在这里翻车：

• 3.6 之前：oplog 条目用 ts（Timestamp）字段做排序和游标，类型是 Timestamp（非 Date）；3.6+ 开始加了 t（term）字段协同判断主节点切换
• 4.0 引入 lsid 和 txnNumber，用于关联事务内的多条 oplog，但仅当操作在显式事务中才出现 → 单条 insert 不会有这些字段
• 某些云托管服务（如 Atlas）默认隐藏 oplog，或只开放只读副本节点的 oplog 访问，且可能禁用 local.oplog.rs 的 direct read 权限

最典型的失败场景：用 Node.js 驱动连 Atlas，代码里写 db.collection('local.oplog.rs').find(...)，结果抛 NamespaceNotFound 或权限错误——不是语法问题，是服务端根本没开这个入口。