确认 Oplog 真的不够用了，别只看 timeDiffHours 这个指标
很多人习惯盯住 db.getReplicationInfo() 返回的 timeDiffHours，认为这就是“还能撑多久”的安全垫。但这里需要提醒的是——这个字段其实只是主节点基于当前写入速率做出的粗略估算，并不可靠。真正需要关注的核心指标，是 Secondary 节点的实际表现。
如何检查？方法很简单：在 Secondary 节点上执行 db.oplog.rs.findOne({ts: {$lt: ObjectId("...")}})，其中 ObjectId 从主节点的 rs.status().members[0].optime.ts 获取。如果返回结果为 null，就意味着该时间点之前的日志记录已经被完全覆盖——这是最直接的告警信号。
此外，还有一些更明显的预警迹象：
- Secondary 的日志中反复出现
OplogStartMissing或Need to reclone collection due to oplog gap错误 - 运行
rs.printSlaveReplicationInfo()时，发现 lag 值持续上升，而timeDiffHours已经小于实际 lag（例如 lag 已达到 3600 秒，但timeDiffHours仅显示 0.8）
MongoDB 4.4+：使用 replSetResizeOplog 在线扩容，但必须满足三个条件
对于已升级到 MongoDB 4.4 及以上版本的用户，有一个在线扩容的实用工具：replSetResizeOplog。这并非简单的“修改配置”，而是通过重置 capped 集合的 maxSize 来实现扩容，整个过程无需重启、不中断读写，体验友好。不过，它也有硬性门槛：
- 所有节点必须至少运行 MongoDB 4.4 版本，且
featureCompatibilityVersion设置为"4.4"（确认方法：执行db.adminCommand({setFeatureCompatibilityVersion: "4.4"})） - 存储引擎必须为 WiredTiger。如果节点仍在使用 MMAPv1，则此方法不可行。
size参数必须使用Double()包裹，单位是 MB，且不能小于 990MB。
具体操作也非常简单。在主节点上执行类似命令：db.adminCommand({replSetResizeOplog: 1, size: Double(10240)})，即可将 Oplog 扩容至 10GB。
这里有几个容易被忽略的细节，需要特别提醒：
- 绝对不要对正处于
initial sync或状态异常（例如卡在STARTUP2）的节点执行此命令。 - 扩容后，建议立即验证：使用
db.getReplicationInfo().maxSizeMB确认新上限是否生效。然后回到 Secondary 节点，再次用findOne测试是否能找到旧的时间戳。
4.2 及更早版本：没有在线选项，滚动重建是唯一可行路径
如果仍在使用 MongoDB 4.2 或更早版本，那么很遗憾，没有“热修改”这种便捷方式。网上有些说法，例如直接删除 local.oplog.rs 或使用 captrunc 操作，这些都是极具误导性的危险做法。强行操作会破坏集合的 capped 属性，轻则节点无法启动，重则导致同步中断。
唯一可靠的方法是逐个进行滚动重建。操作步骤清晰如下：
- 首先停止节点的 mongod 进程
- 找到并删除
data/db/local/oplog.rs.wt文件（注意：只删除此文件，不要删除整个local/目录，也不要删除集合本身） - 重新启动时，添加参数
--oplogSize 10240（单位 MB），指定新的 Oplog 大小 - 等待其自动完成 initial sync
主节点必须放在最后处理。操作前需先执行 rs.stepDown() 让其降级，并确保集群中至少还有一个 Secondary 节点在线提供写服务，否则整个副本集将无法写入。
此方案的风险也需要充分了解：每个节点重建期间都需要完整同步所有数据，耗时与数据量成正比。另外，如果是 config server 副本集，逻辑相同，但必须保持 majority 节点在线，否则 mongos 路由器将无法正常工作。
容易被忽略的关键细节
在实际操作中，最常出问题的地方往往不是命令本身，而是执行节奏和权限等“软环节”：
replSetResizeOplog命令必须在每个节点上单独执行一次。切勿以为只修改主节点就万事大吉，Secondary 节点在同步时仍会依据自身本地的maxSize来判断 Oplog 是否够用。- 执行命令的用户必须具备
clusterManager或clusterAdmin角色权限，否则会被拒绝执行。 - 扩容后，磁盘空间不会自动释放。可以使用
compact命令回收未用空间，但请注意，该操作会阻塞复制过程，因此仅建议在维护窗口期，对已降级的节点谨慎执行。 - 最后一个容易踩的坑：如果运行
db.oplog.rs.stats().maxSize显示只有 2GB，但配置文件中设置了minRetentionHours: 72，那么这只是个“美好愿望”，实际运行中根本无法支撑数小时。物理磁盘空间的限制，才是真正的硬门槛。