不能只调大oplogSizeMB参数解决事务导致的oplog滚动过快问题，因该参数仅初始化时生效；唯一在线调整方式是replSetResizeOplog命令，但仅适用于副本集成员，不支持分片集群的shard或config server。
不能只调大 oplogSizeMB 启动参数来解决事务导致的 oplog 滚动过快问题——该参数仅在节点初始化或重建时生效，运行中修改无效；真正能在线调整的唯一方式是 replSetResizeOplog 命令，但它只适用于副本集成员，**不支持分片集群的 shard 或 config server**。
为什么事务会让 oplog “滚动过快”而不是“写得更多”
事务本身不改变 oplog 条目生成逻辑，但会显著拉长 oplog 的“有效窗口压力”：
- 一个长事务（比如跨 10 秒、更新 5000 文档的
updateMany）会持续占用 oplog 空间，期间新写入不断追加，而 secondary 还没来得及同步完，主节点就不能覆盖旧条目 → 表面看是“滚动快”，实则是“不敢滚” - 事务内对同一文档多次修改（如循环调用
findOneAndUpdate），每改一次就记一条 oplog，哪怕最终值只存最后一次 —— oplog 不合并，只为保证重放一致性 - 事务开启后，所有写操作延迟到
commit才刷盘，但 oplog 条目已在内存中逐条构造完毕，提交瞬间批量落盘，容易触发短时峰值
replSetResizeOplog 是唯一安全的在线扩容方式（但有硬限制）
该命令可立即扩大 oplog.rs 的 maxSize，无需重启，但必须满足三个前提：
- 执行用户需具备
clusterManager或clusterAdmin角色 - size 参数必须用
Double()包裹，例如Double(20000)（单位 MB），传整数如20000会静默失败 - 必须按顺序执行：先所有
SECONDARY，最后PRIMARY；若 primary 先改，可能因 oplog 链断裂导致新 primary 无法提供完整同步流
示例命令：db.adminCommand({replSetResizeOplog: 1, size: Double(20000)})
注意：扩容后磁盘空间不会释放，compact 仅回收未使用空间，且会阻塞复制，**绝不能在 primary 上直接运行**。
分片集群里没法用 replSetResizeOplog？那就只能滚动重建
shard 和 config server 均为独立副本集，但 MongoDB 不允许对其在线调整 oplog 大小 —— replSetResizeOplog 在分片集群中被禁用（Atlas 明确不支持，社区版同理）。
可行路径是滚动重建每个副本集成员：
- 停止单个
SECONDARY节点（用systemctl stop mongod，非kill -9） - 备份并清空
local/目录（保留目录结构，删掉local/oplog.rs及其他 local 文件） - 用新增参数重启：
mongod --oplogSizeMB 4096 --dbpath /data/db ... - 节点自动加入副本集并同步数据，状态变回
SECONDARY后再操作下一个 - 最后对
PRIMARY执行rs.stepDown()，等它降级后再按同样流程处理
config server 必须确保多数派始终可用，否则 mongos 将失联。
最易被忽略的点：事务引发的 oplog 压力，本质是同步链路卡顿的放大器。调大 oplog 只买时间，不治病根；真正要盯的是 db.getReplicationInfo().oldestTimestamp（真实边界）而非 timeDiffHours（估算值），以及 secondary 的 syncSourceHost 是否稳定、是否有持续 RECOVERING 状态。空间够、命令对、顺序准，三者缺一不可。
