直接删掉 dbPath 目录并重启 mongod 是唯一可靠、被官方支持且在 4.4+ 版本中 100% 有效的做法；resync 命令早在 3.2 被移除，现执行必报错；RECOVERING 主因是 oplog 断档或初始同步失败；删前须确认同步源最新、oplog 足够长、磁盘与 IO 充足。
直接删掉 dbPath 目录并重启 mongod 是唯一可靠、被官方支持且在 4.4+ 版本中 100% 有效的做法。别试 resync，它早在 MongoDB 3.2 就被移除了，现在执行只会报 no such cmd: resync。
为什么 resync 命令完全无效
这个命令只存在于已废弃的 master-slave 架构里，副本集（replica set）从 3.2 开始就彻底删掉了它。你在 mongosh 里敲 db.runCommand({ resync: 1 })，得到的永远是错误响应，不是权限问题，是根本没这玩意儿。所有还在提它的教程，基本都基于 2.x/3.0 的老部署方式，对当前 6.x/7.x 完全不适用。
RECOVERING 状态的真实原因只有两个
不是网络抖动或磁盘满导致卡住，而是同步机制本身断了：
-
oplog断档：节点上次同步的时间戳，早于主节点oplog.rs当前最早可用条目的时间戳，日志里典型报错是We are too stale to use candidate as a sync source - 初始同步（initial sync）中途失败且未自动重试：比如磁盘写满、进程崩溃、或 WiredTiger 在低 IO 场景下卡在某个集合克隆阶段（如
"collection": "admin.system.version"长期不动）
查证方法：在 PRIMARY 上跑 db.getReplicationInfo() 看 timeDiffHours；再用 db.oplog.rs.find().sort({$natural: -1}).limit(1) 拿最新 ts，和 RECOVERING 节点日志里报的 “need oplog entry at timestamp X” 对比——X 不在主节点 oplog 里，就是陈旧。
删 dbPath 前必须确认的三件事
否则删完重启照样卡在 RECOVERING：
- 确保你连接的是副本集中
optimeDate最新的 SECONDARY（用rs.printSecondaryReplicationInfo()排序），而不是另一个同样滞后的节点——否则新同步源本身就不够新 - 主节点的
oplog必须足够长：4.4+ 默认由storage.oplogMinRetentionHours控制，不是固定大小；如果太短（比如设成 1 小时），而节点宕机超过 1 小时，就必然陈旧 - 目标节点磁盘空间要充足，且 IO 能跟上：WiredTiger 压缩写入对机械盘很不友好，
InitialSync过程中若持续fsync失败或超时，会静默卡住
删 dbPath 后启动，日志出现 Starting initial sync 和 Cloning collection 才算真正开始。整个过程不依赖任何“软恢复”操作，也不需要手动干预状态切换——SECONDARY 状态是 initial sync 成功后自动进入的，不是靠 rs.stepDown() 或其他命令“推”上去的。
