MongoDB副本集如何实现时间点恢复？

时间点恢复（PITR）必须结合全量快照与oplog回放，前提是oplog覆盖目标时间且备份与oplog匹配；oplog为capped集合，若目标时间早于其最早时间戳则不可恢复。

不能直接靠 mongorestore 实现时间点恢复（PITR），必须结合全量快照 + oplog.rs 回放。关键前提是：你得有覆盖目标时间点的完整 oplog，且备份与 oplog 必须匹配。

确认 oplog 是否覆盖目标时间点

副本集的 oplog.rs 是固定大小的 capped collection，旧日志会被自动覆盖。如果目标恢复时间早于 oplog 最早时间戳，就彻底不可恢复。

1. 在 PRIMARY 节点执行 db.printReplicationInfo()，看 oldest timestamp 是否早于你要恢复的时间
2. 用 db.oplog.rs.find().sort({$natural: -1}).limit(1) 查最新写入时间，用 db.oplog.rs.find().sort({$natural: 1}).limit(1) 查最老时间
3. 注意：printReplicationInfo() 输出的 “oldest” 是估算值，实际以 find().sort({$natural: 1}) 结果为准
4. 如果 oplog 时间窗口太短（比如只保留 2 小时），而你上次备份是 24 小时前，那中间 22 小时的数据就无法还原

使用 mongodump + --oplog 创建可恢复备份

--oplog 不是“开启 oplog”，而是让 mongodump 在备份结束那一刻记录下当前 oplog.rs 的最后位置（即 ts 字段），并把该位置写入备份目录下的 oplog.bson 文件。这个文件是后续回放的基础。

1. 必须在 PRIMARY 上执行，且期间不能发生主从切换（否则 oplog 位置失效）
2. 命令示例：mongodump --host rs0/192.168.10.41:27017 --oplog --out /backup/20260721
3. --oplog 本身不捕获备份过程中的所有变更——它只记一个起始位点；真正用于 PITR 的 oplog 日志，要从备份时刻开始，从副本集实时拉取或从归档中获取
4. 如果你用的是 Ops Manager 或 Atlas，它们会自动管理 oplog 归档和快照对齐，不用手动处理 oplog.bson

还原时回放 oplog 到指定时间戳

先用 mongorestore 恢复全量快照，再用 mongorestore --oplogReplay 回放 oplog ——但这个选项只支持回放到 oplog.bson 记录的那个终点时间，不支持任意时间点。

1. 要精确到秒级时间点，必须手动筛选 oplog：用 mongodump --collection oplog.rs --query '{ts: {$lt: Timestamp(1753158420, 1)}}' 导出截止到某时间的 oplog 子集
2. 然后用 mongorestore --oplogReplay --oplogFile oplog_filtered.bson 应用
3. 注意：回放 oplog 前，目标实例必须停写、关闭 journal（或设 --nojournal）、以 --replSet 模式启动但不加入副本集（避免触发复制）
4. 回放完成后，需手动执行 rs.initiate() 或 rs.reconfig() 重建副本集配置，否则节点无法正常选举

真正容易被忽略的不是命令怎么写，而是 oplog 的生命周期管理和快照-日志对齐。Ops Manager 和 Atlas 把这事封装掉了，但自建环境里，oplog.rs 大小、备份频率、网络延迟导致的 oplog 同步滞后，三者稍一错位，时间点就断档。别等故障了才查 oplog 能不能撑住 24 小时。