oplog是副本集内部复制的副产品，非同步实现机制；其设计仅服务于本集群从节点自动同步，不可用于跨集群同步或手动重放，否则将引发一致性风险。
Oplog 本身不用于“实现”同步，它是同步过程的副产品；MongoDB 副本集的数据同步由复制线程自动完成，Oplog 只是它依赖的日志源。 想手动用 Oplog 做同步（比如跨集群 ETL、审计、CDC），本质是「读取 Oplog 并重放」，但必须清楚这不是官方推荐的生产级同步方案，且极易出错。
Oplog 是什么，为什么不能直接拿来“做同步”
Oplog（local.oplog.rs）是主节点上一个带 TTL 的 capped collection，记录所有写操作（insert、update、delete、command）。从节点通过拉取并顺序应用这些 oplog 条目完成同步 —— 这个过程由 replSet 内部的复制线程全自动管理，用户无法干预或替换。
常见误解是“我读 local.oplog.rs 然后自己 applyOps 就能同步”，但问题在于：
- Oplog 条目不是幂等的（例如
update使用$inc或基于当前值的条件），重放时上下文已丢失 - 没有事务边界，多文档更新/删除可能跨多个 oplog 条目，手动还原一致性极难
- Oplog 格式随 MongoDB 版本变化（如 4.2+ 引入
o2字段用于 pre-image），解析逻辑脆弱 - 从节点可能启用
readConcern: "majority"，而 oplog 中只存 majority-committed 之前的原始 op，直接重放会跳过回滚逻辑
如何安全读取 Oplog（仅限监控、变更捕获场景）
如果目标是监听变更（如构建 CDC 流），应使用 changeStream 而非直读 oplog。它封装了 oplog 解析、错误重试、断点续传和一致性保证：
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
db.collection.watch([
{ $match: { "operationType": { $in: ["insert", "update", "delete"] } } }
], { fullDocument: "updateLookup" })
若必须读 oplog（例如无权限开启 changeStream，或需获取系统级操作），注意：
- 只能在 secondary 上以
readPreference=secondary读local.oplog.rs，主节点读可能阻塞复制 - 必须用
tailable cursor + awaitData，且每次从ts字段（BSON.Timestamp）断点继续，不能依赖 _id - 过滤时用
{ ts: { $gt: Timestamp(...) } }，别用$gte—— Oplog 的ts不保证严格单调递增（尤其跨进程时间漂移时） - 遇到
op: "n"（noop）条目可跳过；op: "c"（command）需特殊处理（如create、drop）
用 oplog 做跨副本集同步的风险点
有人尝试把 A 副本集的 oplog 导出，再在 B 副本集上用 applyOps 命令重放，这在绝大多数情况下会失败：
-
applyOps要求 oplog 条目中的ns（命名空间）在目标集群真实存在，且集合选项（如分片键、collation）完全一致 - Oplog 中的
ui（UUID）字段与源集群绑定，目标集群不认识，导致applyOps报NamespaceNotFound - 涉及
findAndModify或事务的 oplog 条目含内部字段（如lsid、txnNumber），applyOps无法处理 - 即使成功重放，B 集群的 oplog 不会包含这些操作，后续无法被它的从节点同步，形成数据孤岛
真正跨集群同步，请用 mongosync（官方工具）、Debezium（配合 Kafka），或业务层双写 —— 别碰 local.oplog.rs 的重放逻辑。
Oplog 的设计初衷是服务副本集内部复制，不是通用变更日志接口。任何绕过 MongoDB 复制机制、试图“接管”同步的行为，都会在版本升级、故障恢复或负载突增时暴露一致性漏洞。
