必须等当前均衡轮次结束再停balancer，直接执行sh.stopbalancer()不安全；需先用sh.isbalancerrunning()确认无活跃迁移，文件快照备份必须停balancer而mongodump无需；停太久会导致分片失衡，atlas/m0/flex集群不支持该命令。
需要停，但不是无条件硬停；必须等当前均衡轮次结束再停，否则可能引发块（chunk）状态不一致。
sh.stopBalancer() 之前必须确认 balancer 已空闲
直接执行 sh.stopBalancer() 并不安全——如果此时有 chunk 迁移正在进行，该命令会等待迁移完成才返回，但这个“等待”行为容易被误判为卡住或失败。更危险的是，若在迁移中途强制中断（比如 kill 进程或超时退出），config server 的 locks 集合中残留的 balancer lock 可能导致后续元数据操作挂起。
正确做法是先轮询检查：
-
sh.isBalancerRunning()返回false才表示当前无活跃迁移 - 不要只依赖
sh.getBalancerState()，它只反映开关状态，不反映实时运行中与否 - 若
sh.isBalancerRunning()持续返回true，需用sh.status()查看balancer active window和最近迁移日志，确认是否真在迁移，还是因 config server 延迟导致状态未更新
文件系统快照备份必须停Balancer，但 mongodump 不需要
两类备份对 balancer 的要求完全不同：
- 文件快照（LVM/ZFS 等）：必须停
sh.stopBalancer()，且确保sh.isBalancerRunning()为false后再打快照。因为快照捕获的是物理文件瞬间状态，而正在迁移的 chunk 会在多个分片间写入不完整数据块，快照无法保证跨分片一致性 -
mongodump：无需停 balancer，它走的是逻辑读取路径，通过find命令拉取数据，受 MVCC 保护。但要注意：mongodump不能和db.fsyncLock()混用，否则会永久挂起
停太久会导致分片严重失衡，恢复后性能抖动明显
停 sh.stopBalancer() 超过 1 小时，就可能让某些分片的 chunk 数量偏离均值 30% 以上。重启 balancer 后，它会立即触发大量 chunk 迁移，造成：
- 网络带宽集中消耗（尤其跨机房部署时）
- 目标分片磁盘 I/O 暴涨，影响线上查询延迟
- config server 的
chunks集合频繁更新，可能成为瓶颈
建议：备份窗口尽量压缩到 15 分钟内；若无法做到，可在停 balancer 前先手动运行 sh.balanceChucks()（MongoDB 6.0+）做一次预平衡，减少后续补救压力。
Atlas 和 M0/Flex 集群不支持 sh.stopBalancer()
如果你用的是 MongoDB Atlas，注意：sh.stopBalancer() 在 M0 和 Flex 集群上会直接报错 Command not supported。这类集群的备份由 Atlas 自动调度，底层已绕过 balancer 干预——你只需在 UI 中触发备份，或调用 Atlas API 的 /groups/{GROUP-ID}/clusters/{CLUSTER-NAME}/backup 端点即可。
社区版或自托管集群则无此限制，但务必确认连接的是 mongos 实例（不是 mongod），否则会收到 not authorized on admin to execute command balancerStop 错误。
真正容易被忽略的点是：停 balancer 后，sh.status() 输出里仍可能显示 “balancer is running” —— 这其实是旧状态缓存，实际已停。要以 sh.isBalancerRunning() 和 sh.getBalancerState() 组合判断为准，别信界面或 status 的文字描述。
