MongoDB恢复模式下重启后仍无法找到同步节点求助

先给你拆解下日志里的核心问题：你的节点本地最后记录的操作时间戳5ade01e0:66比同步源J-DB-02:27017的最早oplog时间戳5aded094:198还要早，说明这个节点离线太久，同步源已经把它需要的历史oplog给覆盖掉了，复制进程直接把这个同步源拉黑1分钟，结果找不到其他可用同步节点，就一直卡在Recovery模式。

下面是我处理这类问题常用的几种方案：

1. 全量重新同步节点（最彻底的解决办法） #

这是应对数据差距过大问题的标准操作，步骤如下：

• 先停止处于Recovery状态节点的MongoDB服务
• 备份好该节点的数据目录（以防万一），然后删除数据目录下的所有文件和子目录
• 从复制集里健康的主节点/从节点做全量备份，比如用mongodump命令：

  mongodump --host <健康节点地址> --out /path/to/backup
  

• 把备份恢复到当前节点：

  mongorestore --host <当前节点地址> /path/to/backup
  

• 重启MongoDB服务，让节点自动重新加入复制集，等它完成全量同步后就会退出Recovery模式

2. 调整同步源的oplog大小（预防后续再出现同类问题） #

这次的问题本质是oplog保留的历史时长不够，导致离线节点追不上进度。你可以调整同步源的oplog配置来避免下次踩坑：

• 登录到同步源节点的MongoDB shell，查看当前oplog的详细信息：

  db.getReplicationInfo()
  

  这里能看到oplog的大小和当前能保留的历史时间
• 如果保留时间太短，你可以修改MongoDB配置文件里的oplogSizeMB参数（根据业务量设置一个更大的值，比如20480即20G），然后重启同步源节点；若不想重启，MongoDB 3.2+支持动态调整oplog大小：

  db.adminCommand({replSetResizeOplog: 1, size: 20480})
  

  注意：动态调整只能增大oplog容量，无法缩小

3. 紧急情况下临时清除黑名单（仅当数据差距较小时尝试） #

如果只是临时网络波动导致节点短暂离线，你可以先清除对同步源的黑名单，再手动指定同步源试试：

• 在Recovery节点的MongoDB shell里执行：

  db.adminCommand({replSetClearBlacklist: "J-DB-02:27017"})
  

• 然后手动指定同步源：

  rs.syncFrom("J-DB-02:27017")
  

  不过如果数据差距确实像日志里显示的那么大，这个方法大概率没用，还是得用全量同步

最后提醒：全量同步前一定要做好数据备份，大数据集的同步会占用较多资源，建议在业务低峰期操作。

内容的提问来源于stack exchange，提问作者Rishi Tyagi