应动态扩容oplog.rs而非删除，使用replSetResizeOplog命令按secondary先、primary后的顺序逐节点执行，需clusterManager权限且size参数须为Double()包裹；扩容不释放磁盘空间，compact仅在维护窗口对降级节点谨慎使用。
事务执行中 oplog 满了，不能硬等、不能停写、更不能直接删 oplog.rs —— MongoDB 4.0+ 已禁止删除该集合，强行操作会导致副本集不可用。 正确路径是动态扩容 oplog.rs，但必须按节点顺序、带权限、用正确命令执行，否则扩容失败或引发同步中断。
为什么事务期间 oplog 容易满
长事务（尤其是跨文档、带重试的多语句事务）会持续生成大量 oplog 条目；而 WiredTiger 引擎下 oplog 是 capped 集合，空间固定。一旦写满，旧条目被覆盖，secondary 就可能因拉不到完整操作链而进入 RECOVERING 或触发 initial sync。
- 事务本身不产生额外 oplog 类型，但会放大写入密度：每个事务内操作仍逐条记入 oplog
- oplog 保留时长 ≠ 事务窗口，它只反映“当前写速下撑多久”，不是时间戳范围
- 使用
db.getReplicationInfo()查看实际剩余时长，注意timeDiffHours是估算值，oldestTimestamp才是真实边界
用 replSetResizeOplog 动态扩容（MongoDB 4.0+ 唯一安全方式）
该命令支持在线调整，无需停机，但要求用户有 clusterManager 或 clusterAdmin 角色，且必须在每个节点单独执行 —— 不能只改 primary。
- 先连 secondary 节点：
mongosh --host secondary-host:27017 -u admin -p pwd --authenticationDatabase admin - 确认当前大小：
use local; db.oplog.rs.stats().maxSize（单位字节） - 执行扩容（示例调至 20 GB）：
db.adminCommand({replSetResizeOplog: 1, size: Double(20000)}) - size 参数必须是
Double()包裹的数值，且 ≥ 990（单位 MB），传整数会静默失败 - 扩容后
maxSize立即生效，但磁盘空间不会自动释放或回收 —— 这是正常行为
扩容后要不要 compact？什么时候能做
compact 不解决 oplog 满的问题，它只回收已分配但未使用的磁盘空间；而且它会阻塞 oplog 复制，导致节点暂时无法同步。
- 仅当明确要缩减磁盘占用（比如扩容前 oplog 占用 15 GB，扩容后想压回 12 GB），才考虑 compact
- 必须在维护窗口执行，且绝不能在 primary 上直接运行：先
rs.stepDown()降级，再对降级后的节点执行db.runCommand({compact: "oplog.rs"}) - compact 过程中该节点状态变为
RECOVERING，客户端读请求会失败，secondary 也无法从它拉取 oplog - 如果只是扩容防满，跳过 compact 更安全 —— 空间多占点比同步中断代价小
容易被忽略的关键点
最常出问题的地方不在命令本身，而在执行节奏和权限细节：
- 所有 secondary 必须先完成扩容，primary 最后改 —— 否则新 primary 可能因 oplog 太小被 secondary 落后太多而踢出集群
-
replSetResizeOplog返回{"ok":1}不代表立即生效，需等几秒再查stats().maxSize确认 - 阿里云/腾讯云等托管 MongoDB 实例，控制台“调整 oplog”功能底层也是调这个命令，但界面限制最小单位为 GB，且不暴露
Double()封装逻辑，遇到精度需求（如 10.5 GB）必须走 mongosh - 扩容后若仍有频繁覆盖现象，说明写入压力远超预估 —— 这时应检查事务粒度（拆大事务）、索引缺失（导致慢更新堆积 oplog）、或是否存在批量 delete/update 未加 limit
