分片集群中无法统一调整oplog大小，必须逐个对每个shard和config server副本集执行replsetresizeoplog命令或通过控制台分别扩容；mongos无oplog，不参与操作。
分片集群里不能直接调 Oplog 大小
分片集群没有统一的 Oplog；每个分片（shard）和配置服务器（config server）都是独立的副本集，各自维护自己的 Oplog。所以所谓“调整分片集群的 Oplog”，实际是逐个调整每个 shard 和 config server 副本集的 Oplog 容量。mongos 路由层本身不存 Oplog，也不参与复制，无需操作。
常见错误是试图在 mongos 上执行 replSetResizeOplog 或进控制台点“调整 Oplog”却找不到目标——因为控制台默认只展示分片实例（shard）或副本集实例，而你得分别进每个 shard 的实例详情页操作，config server 同理。
- 必须对每个 shard 的主节点（PRIMARY）单独连接并执行调整
- config server 副本集（通常为 CSRS 模式）也需同步扩容，否则在元数据变更频繁时可能先于 shard 被 oplog 覆盖
- Atlas 托管集群不支持
replSetResizeOplog命令，只能通过控制台滑动条调整，且仅限 M10 及以上规格
用 db.getReplicationInfo() 算出最小 Oplog 窗口
Oplog 保留时长不是固定值，它取决于写入速率和当前容量。真正关键的是「最小 Oplog 窗口」（即最短能覆盖多少秒的操作），这个值决定了 mongosync、备份回档、新 secondary 追数据能否成功。
在每个 shard 的 PRIMARY 上运行：
use admin db.getReplicationInfo()
重点关注 timeDiff 字段（单位：秒）。如果有 5 个 shard，分别返回 7200、5400、3600、8100、4500，那最小窗口就是 3600 秒（1 小时）——这就是整个集群的瓶颈。
- 若 mongosync 的
lagTimeSeconds接近该值（比如 > 3000），说明随时可能断连 - 若新 secondary 卡在
RECOVERING状态且日志报could not find member to sync from，大概率是它的同步起点已不在任何 shard 的 Oplog 范围内 -
timeDiff小于 3600 秒时，Atlas 控制台会禁止下调 Oplog 容量
扩容 Oplog 必须停写？不，但有隐性风险
官方文档说调整 Oplog 不需要停机，但实际中仍要避开高峰写入期。原因在于：replSetResizeOplog 是原子操作，但 resize 过程中 MongoDB 会重建 Oplog 集合（本质是 drop + recreate），期间所有写入会被缓冲在内存，若写入洪峰过大，可能触发 WiredTigerCacheOverflow 或导致 oplog 回滚延迟飙升。
- 建议在低峰期执行，且确保节点剩余内存 ≥ 总内存的 25%
- 不要在同一个分片上连续多次 resize（比如 10% → 20% → 30%），两次操作间隔至少 15 分钟
- resize 后立即运行
rs.printSecondaryReplicationInfo()，确认所有 secondary 的optime跟上了，避免隐性不同步 - 云厂商控制台操作（如阿里云、腾讯云）底层也是调用
replSetResizeOplog，同样适用上述约束
目标集群 Oplog 不够大，mongosync 会静默失败
mongosync 同步分片集群时，会在每个 shard 上拉取变更流，再把操作应用到目标集群对应 shard。但它不校验目标端 Oplog 是否够大——如果目标 shard 的 Oplog 容量小于源端，初始同步产生的大量插入/更新操作就会快速填满目标 Oplog，随后被覆盖，导致后续增量同步丢失上下文，最终 mongosync 进程退出，错误日志里只有模糊的 oplog truncated 或 change stream resumetoken invalid。
- 目标集群 Oplog 至少应 ≥ 源集群最大 shard 的 Oplog 容量
- 若启用嵌入式验证（
--enable-embedded-validation），目标 Oplog 还需额外预留 20%～30% 空间，否则验证器跟不上写入节奏 - 别依赖
oplogMinRetentionHours：它只影响后台清理策略，不扩大物理文件大小；真正扩容必须设oplogSizeMB
Oplog 调整不是一次性的运维动作，而是和写入峰值、同步工具行为、备份策略强耦合的持续判断。最容易被忽略的是 config server 的 Oplog ——它不存业务数据，但元数据变更（如 chunk 拆分、balancer 开关）全靠它传播，一旦被覆盖，整个分片集群可能陷入不可控的元数据不一致状态。
