removeshard命令必须在mongos的admin数据库下执行，直接连mongod会报错；需先连接mongos、use admin，且用户须有clustermanager角色权限。
removeShard 命令必须在 mongos 的 admin 数据库下执行
直接连到分片节点（mongod）上运行 removeShard 会报错 not authorized on admin to execute command removeShard，因为该命令只能由 mongos 路由并协调。你得先连上任意一个 mongos 实例，再切换到 admin 数据库：
mongosh --host mongos-host:27017<br>use admin然后才能发命令。如果启用了鉴权，执行用户必须拥有
clusterManager 角色，否则会提示权限不足。
删除前必须确认该分片不是任何数据库的 primary 分片
即使所有集合都已分片，仍可能有未分片数据库（unsharded databases）把该分片设为 primary。这类数据库的数据不会随 chunk 迁移自动搬走，会导致 removeShard 卡在 state: "ongoing" 且 remaining.dbs > 0。查法很简单：
sh.status()或
db.printShardingStatus()重点关注输出里每个数据库的
"primary" 字段。若发现目标分片名出现在其中，必须先用 movePrimary 搬走：db.runCommand({ movePrimary: "myapp", to: "new_shard_name" })这个命令会阻塞，直到全部数据复制完成；完成后**必须**对所有 mongos 执行 flushRouterConfig，否则后续写请求可能路由错误。
draining 状态长期不结束？重点排查 jumbo chunk 和标签残留
常见现象是反复执行 removeShard 始终返回 "state": "ongoing"，remaining.chunks 不归零。原因通常有两个：
- jumbo chunk：某个 chunk 因文档过大或无法拆分而被标记为 jumbo，均衡器跳过它 —— 解决方法是临时调大 config 集合里的 chunk size：
use config<br>db.settings.updateOne({ _id: "chunksize" }, { $set: { value: 1024 } })迁移完再改回 64 - 残留分片标签（tag）：如果该分片曾被配置过
tags（比如dc:west），而对应 tag range 未清理，均衡器会拒绝迁移 —— 查看config.tags并删掉相关记录
removeShard，命令直接被拒绝；社区版和企业版则无此限制。
completed 后别急着关进程，先清空本地 data 目录再重用
当 removeShard 终于返回 "state": "completed"，说明集群元数据已剔除该分片，但原 mongod 实例的 dbpath 里还存着旧数据文件、WiredTiger 日志、journal 等。此时若直接拿这台机器去 addShard，mongos 会接受，但新分片永远不接收写入，所有集合创建失败。正确做法是：停掉该 mongod 进程，手动清空整个 dbpath 目录（不是只删 collections），再重启并加入集群。顺带一提，5.0+ 的 resharding 功能不能替代 removeShard，它只针对单个集合重分布，不涉及物理节点缩容。
