不能直接读取 MongoDB Oplog 因其默认对普通用户不可见，需 clusterMonitor 权限且认证数据库为 admin；安全 tail 需用 tailable+awaitData 游标配合 resumeAfter 恢复位点；解析时需从 o._id 或 o2._id 提取 _id，ns 拆为 ES 索引名；Change Stream 更可靠但依赖 Oplog 容量与驱动版本。
为什么不能直接读取 MongoDB Oplog？
Oplog 是 MongoDB 副本集的内部操作日志，本质是一张 capped collection（local.oplog.rs），但它默认对普通用户不可见——即使有 read 权限，也会被权限系统拦截。直接 db.oplog.rs.find() 会报错：not authorized on local to execute command { find: "oplog.rs", ... }。
必须用具备 clusterMonitor 角色的账号连接，且该账号需在 admin 数据库下创建；否则连 cursor 都拿不到。
- 用
mongosh连接时加--authenticationDatabase admin - 驱动连接字符串里要显式带上
authSource=admin - Oplog 文档里的
ts字段是Timestamp类型（非 ISODate），解析时别误当成Date处理
如何安全地 tail Oplog 并避免漏数据？
“tail”不是靠轮询，而是用 tailable + awaitData 的游标：它能持续等待新写入，类似 Unix 的 tail -f。但关键在于起始位置——如果从当前时间点开始读，必然丢掉已存在但未消费的 oplog。
必须用一个可靠的 resumeToken 或 ts 恢复位点。首次启动时可取 local.oplog.rs.findOne({},{sort:{$natural:-1}}) 拿最新一条的 ts，后续则保存上一次成功同步的 ts 到外部存储（如 Redis 或 ES 自身）。
- 游标选项必须含
{tailable:true, awaitData:true, oplogReplay:true}（oplogReplay在 4.4+ 已废弃，改用resumeAfter） - 不要用
$gt查ts——它不走索引，性能极差；要用resumeAfter: {ts: Timestamp(…)} - 网络断开时，游标自动失效，需捕获
CursorNotFound错误并重连+重置位点
Oplog 解析后怎么映射到 Elasticsearch 的 _id 和 _source？
Oplog 每条记录描述的是单次变更（insert/update/delete），但字段结构不统一：o 是新文档（insert/update），o2 是查询条件（update/delete），ns 是 "db.collection" 格式。
ES 要求每条文档有唯一 _id，而 Oplog 里没有现成 ID。最稳妥的方式是从 o._id 或 o2._id 提取——但要注意：delete 操作只有 o2，insert 只有 o，update 两者都有，且 o 里可能不含 _id（比如 update 不带 $set _id）。
- 优先从
o._id取；不存在则 fallback 到o2._id；都为空就跳过或打日志告警 -
ns字段要拆成db和collection，建议把db.collection作为 ES 的_index名（如myapp.users） - update 操作的
o是修改器（{$set:{...}}），需合并原文档再推送到 ES；实际中更推荐用findAndModify或变更流（change stream）替代原始 oplog 解析
用 Change Stream 替代 raw Oplog 更靠谱吗？
可以，而且应该优先用。Change Stream 是 MongoDB 官方封装的、基于 Oplog 的抽象层，自动处理位点管理、权限封装、格式归一化，还支持按 namespace 过滤、全量+增量无缝衔接。
但它要求：副本集必须开启 majority 读写关注，且 driver 版本 ≥ 3.6（Node.js）、≥ 4.0（Python PyMongo）。更重要的是，它底层仍依赖 Oplog，所以 local.oplog.rs 的大小必须足够覆盖最长消费延迟——比如你处理慢了 1 小时，Oplog TTL 少于 1 小时就会触发 ResumeToken expired 错误。
- 初始化 change stream 时传
{fullDocument: "updateLookup"}，能直接拿到 update 后的完整文档，省去查库 - 务必监听
close和error事件，遇到ChangeStreamFatalError必须重建 stream - 不要在 change stream 回调里做耗时操作（如直连 ES 写入），容易拖垮游标心跳；建议发到队列（如 Kafka / Redis List）异步处理
真正难的从来不是“怎么读”，而是“怎么保证不丢、不重、不错乱顺序”。Oplog 本身无事务语义，跨文档更新、bulk write、回滚都会让顺序和一致性变得微妙——这些细节，往往在压测一周后才浮出水面。
