replSetResizeOplog 仅设置最小日志保留时长（minRetentionHours），不改变 oplog 物理大小；它不扩容磁盘空间，仅在空间充足时尽力保留指定小时数的操作日志，真正扩容必须滚动重建节点并重设--oplogSizeMB。

replSetResizeOplog 是唯一支持运行时调整 Oplog 大小的命令，但它不能“在线”修改物理尺寸——它只重置逻辑保留窗口（minRetentionHours），不改变 local.oplog.rs 集合的 maxSize。所谓“在线”，仅指无需停机，但不会增大或缩小已分配的磁盘空间。

---

replSetResizeOplog 实际作用是什么

• 它不是扩容/缩容 oplog 的物理大小，而是设置一个最小保留时长下限（minRetentionHours），强制 MongoDB 尽量保留至少这么多小时的操作日志
• 该参数仅在 oplog 空间充足、且未被快速覆盖的前提下生效；如果写入压力大，实际保留时间仍可能低于该值
• 不影响 rs.printReplicationInfo() 中的 configured oplog size 字段（该值始终反映启动时 --oplogSizeMB 或配置文件设定的原始大小）
• 仅适用于 MongoDB 4.4+，且必须在每个副本集成员上单独执行

常见误判现象：db.adminCommand({replSetResizeOplog: 1, minRetentionHours: 24}) 执行成功，但 rs.printReplicationInfo().timeDiff 依然只有 0.5 小时 → 说明物理 oplog 太小，根本存不下 24 小时数据，命令只是“提了要求”，没能力兑现

---

为什么 replSetResizeOplog 不能替代真正的 oplog 扩容

• local.oplog.rs 是 capped collection，其 maxSize 在首次初始化时就固定，后续无法通过任何命令变更
• replSetResizeOplog 调整的是内部元数据标记，并非重分配磁盘空间
• 如果你看到 timeDiff 持续低于 1 小时，首要动作是检查 db.oplog.rs.stats().maxSize，而不是调这个命令
• 即使设了 minRetentionHours: 72，若 maxSize 只有 2GB，高写入场景下照样几小时内就被覆盖

典型陷阱：

mongodb-query

用于调试和故障排查，查询MongoDB数据库。用户需要时可以： (1) 列出所有数据库； (2) 列出数据库中的集合； (3) 执行MongoDB查询或命令。

下载

• 误以为执行 replSetResizeOplog 后 oplog “变大了”，结果同步延迟仍触发 STALE 状态
• 在 primary 上先执行，导致选举期间 secondary 无法获取足够 oplog 追平，被迫 initial sync
• 未验证目标节点是否已升级到 4.4+，命令返回 "errmsg" : "no such cmd"

---

真正扩容 oplog 的唯一路径：滚动重建

• 必须逐个处理 secondary 成员：停止进程 → 清空 local/ 目录（保留目录结构）→ 用新 --oplogSizeMB 参数重启 → 等待自动同步完成
• primary 必须最后处理，且需先 rs.stepDown()
• config server 副本集同理，但必须保证 majority 始终可用（否则 mongos 失去路由能力）
• 所有节点的 maxSize 改变后，rs.printReplicationInfo() 中的 configured oplog size 才会更新

关键细节容易被跳过：

• 清空 local/ 时不能删掉 _mdb_catalog.wt 或 journal/ —— 这些不属于 oplog，删了节点起不来
• 重启前没备份原 oplog.rs 最后一条记录，新 oplog 初始化后无起始同步点，secondary 会卡在 RECOVERING
• 配置文件里改了 replication.oplogSizeMB，但启动时没加 --config 参数，实际仍按旧参数运行

真正决定同步稳定性的，永远是 db.oplog.rs.stats().maxSize 的字节数，不是某个命令返回的“ok”。