MongoDB的复制集之所以能够实现数据同步，靠的就是oplog这个特殊的固定集合（capped collection）。主节点每执行一次写操作，都会往local库的oplog.rs集合里写入一条记录，从节点不断拉取这些记录并在本地回放。如果oplog容量太小，一旦从节点宕机时间超过oplog覆盖的时间窗口，重新上线时就无法增量同步，只能触发全量的initial sync，数据量大时代价非常高昂。所以在生产环境中，学会查看和调整oplog大小是一项必备技能。
一、查看当前oplog的状态和大小
在动手调整之前，先要弄清楚当前oplog的实际情况。最常用的命令是rs.printReplicationInfo()，它会输出oplog的大小以及最早一条记录的时间戳，从而推算出oplog当前能覆盖多长时间窗口。
rs.printReplicationInfo() // 输出示例： // configured oplog size: 1024MB // log length start to end: 86400 (86400 secs) // oplog first event time: Mon Jan 15 2024 08:00:00 GMT+0800 // oplog last event time: Tue Jan 16 2024 08:00:00 GMT+0800 // Now: Tue Jan 16 2024 08:05:00 GMT+0800
也可以直接查看local库中的元数据信息：
use local db.getReplicationInfo() // 返回包含 logSizeMB、timeDiff、tFirst、tLast 等字段
重点关注log length start to end这个秒数，它表示当前oplog能覆盖的时间跨度。一般来说，这个窗口至少要大于从节点最长的预期宕机时间，同时也要能容纳常见的备份任务、索引构建等耗时操作的周期。如果只有几个小时甚至更短，就存在明显风险。
另一个需要理解的点是，oplog是一个capped collection，它会按照插入顺序循环覆盖旧数据，写入速度取决于业务写入量。同样的1GB oplog，写入频繁的业务可能只够覆盖1小时，而写入稀疏的业务可能覆盖好几天，所以评估时要结合写入速率来看时间窗口，而不是只看容量数字。
二、使用replSetResizeOplog调整oplog大小
从MongoDB 3.6开始，官方提供了在线调整oplog大小的命令replSetResizeOplog，它以管理命令的形式执行，不需要重启实例，也不会中断服务。执行方式如下：
use admin
db.adminCommand({
replSetResizeOplog: 1,
size: 20480 // 单位是MB，这里表示调整为20GB
})
size参数的单位是MB，最小值是990MB，低于这个值会报错。扩容是立即生效的，集合会自动增长；而缩容则不会立刻回收磁盘空间，MongoDB只是标记了一个较小的逻辑上限，后台会逐步删除尾部多余的文档，实际磁盘占用需要等待后续写入覆盖后才逐渐下降。
需要特别注意的一点是，replSetResizeOplog只对当前连接所在的节点生效，不会自动同步到复制集的其他成员。正确做法是对复制集中的每个节点逐一执行，包括主节点和所有从节点。操作顺序上建议先改从节点，最后改主节点，降低对主节点的影响。可以通过db.isMaster().me或者rs.status()确认当前连接的是哪个节点。
执行成功后，可以再次运行rs.printReplicationInfo()验证configured oplog size是否已经变化。对于分片集群，每个分片的复制集都需要分别处理，mongos路由节点上没有oplog，config server的复制集如果需要调整也要单独操作。
三、旧版本的做法与新命令的对比
在3.6之前的版本中，调整oplog大小是一件比较麻烦的事情，通常的做法是：先把目标节点移出复制集或降级，停止实例后删除local库中的oplog.rs集合，再修改配置文件中replication.oplogSizeMB参数，最后重启实例让MongoDB重建oplog。整个过程需要停机，操作步骤多，容易出错。
相比之下，replSetResizeOplog的优势非常明显：完全在线执行、逐节点操作不影响整体可用性、命令简单不易出错。下面的表格对比了两种方式的核心差异：
| 对比项 | 传统方式（删集合+改配置+重启） | replSetResizeOplog |
|---|---|---|
| 是否需要停机 | 需要 | 不需要 |
| 操作复杂度 | 高，步骤多 | 低，一条命令 |
| 最低版本要求 | 无 | 3.6及以上 |
| 是否对全副本集生效 | 逐节点操作 | 逐节点操作 |
还有一种思路是在初始部署时就把oplogSizeMB设置得足够大，比如磁盘空间的5%到20%，从源头上避免后续调整。但业务写入量往往是动态增长的，预设值未必永远合适，所以掌握在线调整命令依然重要。
四、常见问题与注意事项
第一，缩容操作要谨慎。如果缩容后的时间窗口小于从节点的同步延迟，从节点会立刻进入RECOVERING状态，需要人工介入甚至重新initial sync。缩容前务必评估实际的写入速率和延迟情况。
第二，调整命令需要在admin库下以adminCommand执行，并且要求执行者具备相应的管理权限。如果在仲裁节点上执行会失败，因为仲裁节点不存储数据，没有oplog集合。
第三，隐藏节点、延迟节点同样需要调整。很多人只改了主节点和一个从节点，漏掉了延迟从节点，结果延迟节点的窗口不足导致同步失败。建议先执行rs.conf()列出所有成员，逐个确认。
第四，调整完成后要做持续观察。可以在监控系统中跟踪oplog窗口时长的变化趋势，如果写入量增长导致窗口持续缩短，就应该提前扩容，而不是等到出现复制延迟告警才处理。合理的oplog大小没有固定标准，核心指标是保证时间窗口覆盖从节点可能的最长离线时间，一般建议至少保留24到72小时。
MongoDBoplogreplSetResizeOplog修改时间：2026-09-07 04:24:31