停机前必须确认三件事：关闭负载均衡器、确保无进行中的chunk迁移、严格按mongos→shard→config server顺序关机。
停机前必须确认的三件事
分片集群不是单机MongoDB，乱关服务会导致元数据损坏、块迁移中断、应用写入丢失。重启前不检查，等于给集群埋雷。
- 运行
sh.getBalancerState()确认负载均衡器已关闭；没关就停 config server，正在迁移的数据块会卡死 - 执行
sh.stopBalancer()并等待返回true，再用sh.isBalancerRunning()双重验证 - 检查是否有进行中的 chunk 迁移：连接任意
mongos运行db.adminCommand({listCurrentOperations: 1, $all: true})，过滤出"command" : "moveChunk"的操作——必须等它完成或手动中止（sh.stopBalancer()通常会等，但不能赌）
关机顺序错一步，集群就“假死”
config server 是集群的“大脑”，shard 是“手脚”，mongos 是“门卫”。关错顺序，mongos 启不来，shard 找不到配置，整个集群对外失联。
- 先关所有
mongos：连上每个mongos的admin库，执行use admin→db.shutdownServer() - 再关所有 shard 副本集：**严格按从节点→主节点顺序**。进每个副本集成员的
admin库执行db.shutdownServer()，确保 PRIMARY 最后关 - 最后关 config server 副本集：同样**从节点先关，PRIMARY 最后关**。config server 不支持单点，关早了 mongos 启动时直接报
Failed to load config database
开机顺序比关机更容错？不，错得更隐蔽
开机顺序反了不会立刻报错，但可能让集群“看似正常，实则残废”：比如 config server 没完全初始化好，mongos 就连上了，结果路由表加载不全，某些 chunk 查不到，查询静默失败。
- 必须 **config server 全部启动并完成初始化**（日志出现
Waiting for connections且rs.status().members[n].stateStr === "PRIMARY"）才能启 shard - shard 启动后，**逐个验证副本集状态**：
mongo --host shard1-node1:27018 --eval "rs.status().ok"返回1才算稳 - mongos 必须等所有 config server 和所有 shard 都 ready 后再启；命令里漏掉
--configdb或地址写错，它会启动成功但无法路由，查sh.status()会发现config server status: Unknown
systemd 管理下最容易被忽略的陷阱
用 systemctl restart mongod 看似省事，但在分片部署里极危险——你根本不知道这个 unit 对应的是 config、shard 还是普通单机实例，一按就全崩。
- 每个角色必须用独立 service 文件，例如
mongod-config.service、mongod-shard1.service，并在[Service]段指定不同ExecStart，如/usr/bin/mongod -f /etc/mongod/config.conf - 禁止对 config server 使用
--bind_ip_all，必须显式写--bind_ip=192.168.1.10,127.0.0.1，否则 mongos 连不上（默认只允许 localhost 连 config） - mongos 服务不能用
mongodunit，必须单独建mongos.service，ExecStart指向/usr/bin/mongos，且必须带--configdb参数，例如--configdb cfgReplSet/192.168.1.10:27019,192.168.1.11:27019
