深入理解MongoDB的Oplog机制_数据同步核心与Oplog大小设置-MongoDB-PHP中文网

oplog是mongodb副本集中记录写操作的固定大小capped集合，不可删除或清空，否则导致节点无法启动或同步；其大小决定数据同步窗口，可通过rs.printreplicationinfo()查看，不足1小时易引发stale状态和全量重同步。

深入理解mongodb的oplog机制_数据同步核心与oplog大小设置

Oplog 是什么，为什么它不能被删或清空

Oplog（Operation Log）是 MongoDB 副本集里每个节点都维护的一张特殊的 capped collection，路径固定为 local.oplog.rs。它不是日志文件，而是一张带时间戳的、按写入顺序排序的集合，记录所有改变数据的写操作（insert、update、delete、command）。Secondary 节点靠不断拉取并重放 Oplog 来保持和 Primary 的数据一致。

它不能被 drop 或 deleteMany({})，因为 MongoDB 内部强依赖它的存在和结构——一旦缺失或损坏，副本集会直接拒绝启动或进入 RECOVERING 状态，无法同步。

用 db.getSiblingDB("local").oplog.rs.drop() 会导致该节点永久不可用，必须重新初始化
db.local.oplog.rs.remove({}) 在 4.4+ 版本会被拒绝执行，返回 CommandNotSupportedOnCappedCollection
即使绕过限制清空了内容，Oplog 的 capped 属性仍在，但起始位置丢失，Secondary 将无法确定从哪条日志开始同步

怎么查当前 Oplog 大小和可保留时长

Oplog 大小是固定的（创建副本集时由 --oplogSize 或配置项 replication.oplogSizeMB 决定），但它能存多久的数据，取决于你的写入压力。高吞吐场景下可能只撑 10 分钟，低频业务可能存 72 小时以上。

查大小和窗口期最直接的方式是运行：

rs.printReplicationInfo()

它会输出类似：

configured oplog size:   4096MB
log length start to end: 12345secs (3.43hrs)
oplog first event time:  Mon Apr 01 2024 10:23:45 GMT+0000 (UTC)
oplog last event time:   Mon Apr 01 2024 13:47:30 GMT+0000 (UTC)

log length start to end 是当前 Oplog 中最早到最晚事件的时间差，即“有效窗口”
这个值会随写入持续滑动，不是静态指标；如果写入暂停，它会缓慢增长（因无新日志覆盖旧日志）
低于 1 小时就该警惕：Secondary 如果落后超过这个时长，就会触发 Stale 状态，无法再通过 Oplog 追平，只能全量重同步（initial sync）

Oplog 太小导致同步中断的典型现象

最常见的报错不是“Oplog full”，而是 Secondary 日志里反复出现：

replSet error: Need to reclone collection ... due to oplog gap

或在 rs.status() 中看到某个节点状态为 STARTUP2 卡住、RECOVERING 长时间不转 SECONDARY，甚至直接变成 UNKNOWN。

根本原因是 Primary 的 Oplog 已把 Secondary 还没拉取的老日志覆盖掉了，Secondary 请求一个已不存在的 ts（时间戳），触发 OplogStartMissing
此时 rs.printSlaveReplicationInfo() 会显示该节点的 syncedTo 时间远早于 Primary 的 oplog last event time，差值大于 Oplog 窗口
不要试图用 resync 命令修复——它只适用于网络闪断等瞬时问题；一旦确认是 Oplog 覆盖，唯一办法是删掉 data/db 下该节点的数据目录，让其重新 initial sync

调整 Oplog 大小的实操要点

Oplog 是 capped collection，不能直接 alterCollection。要扩容，必须停机、备份、重建 Oplog，且仅限副本集（非分片集群的 config server 不适用）。

步骤本质是：停 Secondary → 清空其数据 → 启动并指定更大 --oplogSize → 让它自动重建 Oplog 并同步。

不能只改配置重启：老 Oplog 文件仍存在，MongoDB 会复用它，不会重建
必须先删除 local.oplog.rs 对应的磁盘文件（通常在 data/db/local.0、local.1 等），否则新进程仍加载旧结构
推荐做法：停节点 → 删除整个 data/db 目录 → 修改启动参数增加 --oplogSize 10240（单位 MB）→ 启动 → 观察 rs.printReplicationInfo() 确认新大小生效
注意：扩容后 Oplog 内容为空，Secondary 会从 Primary 当前最新位置开始同步，所以务必确保 Primary 的 Oplog 窗口足够宽，能撑到该节点追上

真正难的从来不是改数字，而是判断“够不够”。写入峰值、批量导入、慢查询阻塞复制线程……这些都会压缩有效窗口。留余量别只看平均值。