应合并多次更新为单次原子操作、禁用事务内save()、逐节点按序动态扩容oplog并用Double()指定大小，避免compact；updateMany和bulkWrite在事务中仍会生成多条oplog。
事务中反复更新同一文档会撑爆Oplog，怎么避免
事务里对同一个文档执行多次 findOneAndUpdate、save() 或分步 $set，每改一次就记一条 oplog —— 不合并、不压缩，只按执行顺序落盘。这直接导致 oplog 条目数暴增，尤其在状态流转类逻辑（如 pending → processing → done）中极易触发。
- 检查应用代码是否存在「查→改A→改B→改C→提交」这类低效模式，强制合并为单次原子更新，例如
{$set: {status: "done", updated_at: new Date(), retry_count: 3}} - 禁用 ORM 封装的
doc.save()在事务内调用，它常隐式触发多次写入；改用原生updateOne并显式传入完整字段集 - 用
db.adminCommand({currentOp: {allUsers: true, $or: [{secs_running: {$gt: 5}}, {active: true}]}})抓出长事务，重点看numYields和secs_running，它们往往暴露了循环更新或阻塞等待
扩容 oplog.rs 必须用 replSetResizeOplog，不能删也不能停写
MongoDB 4.0+ 已禁止删除 oplog.rs，硬删会导致副本集不可用；等它自己覆盖也不是办法——secondary 可能因拉不到连续操作链而进入 RECOVERING 或触发 initial sync。唯一安全路径是在线动态扩容，但必须满足三个硬条件：权限、顺序、参数格式。
- 用户需具备
clusterManager或clusterAdmin角色，普通dbOwner权限不够 - 必须逐节点执行，且严格按
secondary → primary顺序：先在一个 secondary 上跑完命令，确认状态正常（rs.status()中无STARTUP2或RECOVERING），再切到下一个，最后动 primary -
size参数必须用Double()包裹，单位是 MB；传整数（如20000）会静默失败，正确写法是Double(20000)，且值不得小于990
updateMany 和 bulkWrite 在事务里照样放大 oplog
事务不改变 oplog 的生成规则：updateMany 匹配 N 条文档，就写 N 条 oplog；bulkWrite 中每个 updateOne 操作也各自独立记日志。事务只是把它们包进一个原子上下文，不是压缩器。
- 批量状态迁移（如订单从
created到delivered）若放在一个事务里执行，oplog 条目数 = 实际更新文档数 × 更新次数，务必评估该数量是否超过当前 oplog 容量支撑能力 - 不要误以为
writeConcern: {w: "majority"}能缓解 oplog 压力——它只影响写确认级别，不减少日志条目数 - 监控真实压力要盯
local.oplog.rs的增长速率和平均条目大小，而不是serverStatus.metrics.operation.write.ops这类请求计数指标
扩容后要不要 compact？绝大多数情况应该跳过
compact 不解决 oplog 满的问题，它只回收已分配但未使用的磁盘空间，而且会阻塞 oplog 复制，让节点暂时无法同步。它的代价远高于多占点磁盘。
- 仅当明确要缩减磁盘占用（比如扩容前 oplog 占 15 GB，扩容后想压回 12 GB），才考虑
compact - 必须在维护窗口执行，且绝不能在 primary 上直接运行：先
rs.stepDown()降级，再对降级后的节点执行db.runCommand({compact: "oplog.rs"}) -
compact过程中该节点状态变为RECOVERING，客户端读请求失败，其他 secondary 也无法从它拉取 oplog —— 这个风险在生产环境通常不可接受
secondary → primary 顺序逐个执行，或者在某个节点上还没确认状态就急着切下一个，就可能引发同步中断。这不是命令失败，而是副本集隐性失联。 
