rs.printReplicationInfo()是最直接可靠的方式，返回log length start to end（秒）、timeDiffHours（小时）及首尾时间戳；db.getReplicationInfo()返回结构化JSON供脚本解析；不推荐直接查oplog.rs计算时间差。
用 rs.printReplicationInfo() 快速查看 Oplog 时间窗口
这是最直接、最可靠的方式，专为副本集设计，会自动计算当前 oplog.rs 中最早和最新操作的时间差，并换算成小时数。
在 mongosh 中连接到 Primary 节点后执行：
rs.printReplicationInfo()
输出中关键字段含义：
-
log length start to end：以秒为单位的总覆盖时长（比如587282secs） -
timeDiffHours：等效的小时数（比如163.37） -
oplog first event time和oplog last event time：首尾操作的精确时间戳，可用于交叉验证
注意：该命令仅在 Primary 上有效；Secondary 执行会报错或返回空结果。
用 db.getReplicationInfo() 获取结构化数据
如果需要在脚本里解析（比如监控告警），db.getReplicationInfo() 返回的是 JSON 对象，字段名更规范，适合程序读取。
执行后你会看到类似：
{
"logSizeMB": 5018.0009765625,
"usedMB": 5037.85,
"timeDiff": 588136,
"timeDiffHours": 163.37,
"tFirst": "Fri Dec 22 2017 18:09:22 GMT+0800 (CST)",
"tLast": "Fri Dec 29 2017 13:31:38 GMT+0800 (CST)",
"now": "Fri Dec 29 2017 13:31:38 GMT+0800 (CST)"
}
其中 timeDiff 就是秒级差值，tFirst/tLast 是字符串格式时间，不建议直接用它们做减法——MongoDB 内部用的是 Timestamp 类型，手动解析容易出错。
别直接查 db.oplog.rs 来算时间差
虽然 db.oplog.rs.find().sort({$natural: -1}).limit(1) 能拿到最新一条，db.oplog.rs.find().sort({$natural: 1}).limit(1) 能拿到最老一条，但实际不推荐这么干，原因有三：
- Oplog 是 capped collection，
$natural: 1不一定返回“时间上最早”的那条——它只保证插入顺序，而 oplog 的写入可能跨线程、有微小乱序 - 遍历整个 oplog 效率极低，尤其当集合很大时，会明显拖慢 Primary
- 结果不可靠：
ts字段是Timestamp类型（4字节秒 + 4字节计数），不能直接用 JavaScriptDate相减，容易得到错误毫秒数
真正需要 inspect 单条 oplog 内容时，用 db.oplog.rs.findOne({}) 看结构即可，别用来推时间窗口。
时间差变短？先看写入压力再调大小
如果 timeDiffHours 明显低于预期（比如只剩 2 小时），说明 oplog 正被快速填满。这不是单纯“磁盘不够”的问题，而是单位时间写入量过大导致覆盖过快。
- 检查是否近期有大批量
delete或update操作——这类操作每影响一个文档就记一条 oplog，极易撑爆窗口 - 确认
oplogSizeMB设置是否合理：默认是磁盘的 5%，但对高吞吐实例常需手动调大（如 20GB～100GB） - 云数据库（如阿里云 MongoDB）可通过控制台「更多 > 查看/调整 Oplog」在线扩容，但注意切换时会有秒级闪断
真正难处理的不是怎么查，而是查完发现时间窗口只有几十分钟——这时候得结合业务写入节奏，反推需要多大的 oplog 才能兜住故障恢复窗口。
