oplog瓶颈源于事务设计缺陷而非配置问题；单次事务操作过多导致oplog条目膨胀、同步延迟甚至副本集失联，需从代码层控制事务粒度，拆分批量写入并避免伪原子操作。
单次事务操作数量过多，直接导致 oplog 条目膨胀、同步延迟甚至副本集失联——这不是配置问题，是事务设计缺陷。
为什么 db.runCommand({logRotate:1}) 不能解决 oplog 过大
很多人混淆了「日志文件」和「oplog」：前者是 MongoDB 启动时用 --logpath 写入的诊断日志（server.log），后者是 local.oplog.rs 集合里记录的数据变更历史，专供副本集同步使用。调用 logRotate 只能滚动服务端诊断日志，对 oplog 完全无效。
- oplog 是固定大小的 capped collection，空间耗尽后会覆盖最老条目
- 一个长事务写入大量文档，会在 oplog 中生成等量条目（哪怕只在一个事务里）
- Secondary 节点必须按顺序重放 oplog；单个事务太大 → 单条 oplog 记录过大 → 复制卡住或超时
如何判断 oplog 是否已成瓶颈
连接任意副本集节点（推荐 Secondary），运行：
db.getReplicationInfo()
重点关注三个字段：
-
logSizeMB：当前 oplog 分配的总空间（不是磁盘占用） -
timeDiffHours：最新 oplog 条目与最老条目之间的时间跨度 -
usedMB（需手动计算）：logSizeMB × (1 - (oldestTimestamp - newestTimestamp) / totalWindowSeconds)，但更简单的是看timeDiffHours是否远小于你期望的保留窗口（比如只有 2 小时，但业务要求 24 小时容错）
如果 timeDiffHours ，说明 oplog 正在被高频覆盖，新加入的 Secondary 很可能无法追上主节点。
控制事务粒度：从代码层切断 oplog 溢出源头
MongoDB 的事务本身不压缩变更，每个 insertOne、updateOne、deleteOne 在提交时都会生成独立 oplog 条目。哪怕封装在同一个 session.withTransaction() 里，也无法合并。
- 避免在事务中执行批量写入：把
bulkWrite([...])拆成多个小事务，每批 ≤ 1000 条（根据文档平均大小动态下调） - 禁用「伪原子」习惯：不要为单个
updateMany({status: "pending"}, {$set: {status: "done"}})包裹事务——它本质是 N 条独立更新，应直接执行 - 检查驱动版本：Node.js 驱动 4.13+、Python PyMongo 4.7+ 对大事务有更明确的
maxCommitTimeMS和wtimeout提示，旧版本可能静默失败 - 监控真实 oplog 条目数：在事务内插入前加计数器，或用
db.currentOp({secs_running: {$gt: 5}})抓长期运行事务
真正有效的 oplog 扩容只能离线做
在线扩 oplog 不被支持。唯一安全方式是逐台维护 Secondary：
- 停止一个 Secondary 进程
- 用
mongod --dbpath /data/db --port 27018 --replSet rs0单机模式启动 - 执行：
use local db.oplog.rs.drop() db.createCollection("oplog.rs", {"capped": true, "size": 10737418240}) // 10GB - 关闭单机 mongod，改回原配置重启，等待重新同步
注意：size 值必须是 2 的幂（如 2048、4096、10737418240），且扩容后不会自动提升 timeDiffHours——它取决于你单位时间写入的 oplog 数据量，不是单纯靠空间大就能撑久。
事务里塞 5 万条更新，哪怕 oplog 有 100GB，也可能 3 分钟就刷完。根源永远在事务设计，不在 oplog 大小。
