应设为覆盖最长停机/同步窗口与写入速率组合，静态上限不超实例最大存储30%，批量写入或同步周期长时需调大；replSetResizeOplog须按secondary先、primary后顺序执行，用clusterManager权限及Double()包裹size参数。
oplogSizeMB 参数怎么设才不会被覆盖
oplog 被覆盖的直接原因是写入量超过其容量，导致旧操作被循环擦除。关键不是“设多大”，而是让 oplogSizeMB 覆盖住你的「最长停机/同步窗口 + 写入速率」组合。
默认值（WiredTiger 引擎下为 5% 可用磁盘空间，最小 990 MB）在多数中小业务中够用，但以下场景必须调大：
- 批量导入、定时任务集中写入时，
rs.printReplicationInfo()显示的oplog window小于 24 小时 - 使用
mongosync同步大型数据集，且同步周期可能超过当前 oplog 窗口 - 从节点因网络或负载偶尔延迟拉取，历史 lag 曾达数小时
静态设置时，建议上限控制在实例最大可用存储的 30% 以内；若需更大，优先扩容磁盘而非硬塞参数。
replSetResizeOplog 命令执行要注意什么
这个命令能在线调整 oplog 大小，但顺序和权限容易出错。
必须按「先从节点、再主节点」顺序执行，否则主节点 resize 后，从节点可能因 oplog 不一致拒绝同步。
执行前确认：
- 连接用户具备
clusterManager或clusterAdmin角色（对local数据库有写权限） - 目标 size 是
Double()类型，比如Double(16000)表示 16 GB，不能传整数或字符串 - size 值必须 ≥ 990（单位 MB），否则命令直接失败
命令示例：db.adminCommand({ replSetResizeOplog: 1, size: Double(16000) })
调大 oplog 后磁盘空间没释放？
这是常见误解：增大 oplogSizeMB 或执行 replSetResizeOplog 只是逻辑扩容，不自动回收旧空间；减小 size 更不会自动缩容磁盘。
如果之前 oplog 占用过大，现在想真正释放磁盘，必须手动运行 compact：
- 只能在从节点上执行（主节点先
rs.stepDown()降级） - 执行期间该节点无法复制 oplog，必须安排维护窗口
- 命令是：
use local→db.runCommand({ "compact": "oplog.rs" })
注意：compact 不影响复制一致性，但会短暂阻塞 oplog tailing。
oplog window 和实际保留时间不是一回事
rs.printReplicationInfo() 输出的 oldest timestamp 到 latest timestamp 差值，只是当前 oplog 的「时间跨度」，不是保证保留时长。
它受写入节奏影响极大：低峰期可能显示 72 小时，高峰期可能掉到 3 小时。真正决定「能回档多久」的是这个窗口的最小值 —— 尤其在分片集群中，要取所有 shard 的最小值。
监控时别只看单次输出，应持续采集 timeDiff 字段并告警：当连续 3 次低于你业务要求的最低窗口（如 8 小时），就该介入了。
