cleanupOrphaned命令仅适用于分片集群的shard节点primary，因副本集无分片元数据、无config server、未启用shardsvr角色，故执行时返回“no such cmd”；其设计专用于清理迁移残留孤儿文档，不适用于副本集的数据不一致问题。
不能在副本集成员上执行 cleanupOrphaned 命令——它只适用于分片集群中的 shard 节点，且必须是该 shard 所在副本集的 primary。
为什么在副本集上运行 cleanupOrphaned 会失败
该命令设计初衷就是处理分片迁移后残留的“孤儿文档”，而副本集本身不参与分片逻辑，没有 chunk 元数据、没有 config server、也没有迁移上下文。你在普通副本集节点（哪怕它是 primary）上执行：
db.runCommand({ cleanupOrphaned: "db.col" })
会直接返回 "no such cmd" 或 "command not found" ——因为 mongod 启动时根本没加载这个命令，除非它被明确配置为分片角色（即作为 shard server 运行）。
- 副本集 mongod 启动参数中不含
--shardsvr - 配置文件里没设置
sharding.role: shardsvr - config server 里查不到该节点所属的 shard 名称
cleanupOrphaned 的真实执行位置和前置条件
它只能在满足以下全部条件的 mongod 实例上运行：
- 该实例是某个 shard 的一部分（即启动时加了
--shardsvr或配置了sharding.role: shardsvr） - 你连接的是该 shard 所在副本集的 当前 primary（不是 mongos，不是 secondary，不是 config server）
- 已通过
use切换到目标数据库（如use mydb），再调用命令 - 命令中传入的命名空间格式必须是
"mydb.mycoll"（字符串，带库名，不加引号外层）
常见错误示例：
db.runCommand({ cleanupOrphaned: "mycoll" }) // ❌ 缺少库名，格式错误
db.runCommand({ cleanupOrphaned: "mydb.mycoll" }) // ✅ 正确，但前提是已在 mydb 库下执行
副本集中出现类似“孤儿”现象？先确认是不是真问题
如果你在副本集里发现同一条文档出现在多个节点、或 find() 结果不一致，大概率不是“孤儿文档”，而是：
-
readConcern: "available"下从 secondary 读到了未提交/回滚的 oplog 中间状态 - 写操作用了
writeConcern: { w: 1 }，但主节点写入后宕机，secondary 没来得及同步就升主 - 手动使用
rs.syncFrom()或异常恢复导致数据不一致（此时应做 resync，不是清理）
这类问题无法靠 cleanupOrphaned 解决。正确做法是：
- 用
db.adminCommand({ replSetGetStatus: 1 })检查各成员 optime 和 state - 对比主从节点上同一查询的
explain("executionStats")输出，看是否命中相同索引和计划 - 必要时对特定节点执行
rs.syncFrom("primary-host:port")强制重同步
真正需要清理时，别跳过 chunk 边界校验
即使你确认是在 shard 节点的 primary 上操作，cleanupOrphaned 也**不会自动判断某条文档是否该删**——它只是等待后台异步清理完成。而实际清理动作依赖 config server 中的 chunk 元数据是否准确。所以执行前必须人工验证：
- 运行
db.getSiblingDB("config").chunks.find({ ns: "mydb.mycoll" }).sort({ min: 1 })，检查min/max是否连续、无空隙、无重叠 - 抽样几条疑似“孤儿”的文档，用其分片键值手动比对是否落在所有 chunk 范围之外
- 确认 balancer 已停、无正在进行的
moveChunk（查db.getSiblingDB("config").locks.find({ _id: "balancer" })）
漏掉这一步，cleanupOrphaned 可能永远卡在 "waiting for orphan cleanup"，或者等来的根本不是你期望的结果。
