sh.setBalancerWindow() 是 MongoDB 5.0 分片集群中设置迁移时间窗口的唯一正确方式，直接写入 config.settings 集合，需在 mongos 上执行，时间格式为 "HH:MM"，跨日合法，生效延迟默认 10 分钟，仅控制新迁移启动时机。
sh.setBalancerWindow() 是设置时间窗口的唯一正确方式
在 MongoDB 5.0 分片集群中，sh.setBalancerWindow() 是官方支持且唯一推荐的设置迁移时间窗口的方法。它直接写入 config.settings 集合的 balancer 文档，所有 mongos 实例共享该配置。不要用 db.settings.update() 手动更新，那属于过时操作，容易因格式错误或字段遗漏导致窗口不生效。
常见错误现象包括：sh.status() 中 activeWindow 仍为 null、迁移仍在非预期时段发生、多个 mongos 执行不同窗口命令后以最后一次为准但未生效——这通常是因为没在 mongos 上执行，或执行后没等下一个平衡周期（默认 10 分钟）。
- 必须连接到任意一个
mongos执行，不能连 config server 或 shard - 时间格式严格为
"HH:MM"，例如"22:00"，不支持秒、AM/PM、时区缩写 - 跨日区间如
{ start: "22:00", stop: "06:00" }是合法的，MongoDB 内部按 UTC 解析 - 执行后不会立即生效，下一次平衡器检查（默认每 10 分钟）才会读取新配置
activeWindow 是白名单，不是定时任务
activeWindow 控制的是“允许启动迁移”的时间段，不是 cron 式调度器。只要迁移任务在窗口内开始，即使运行超时（比如一个 moveChunk 耗时 2 小时），也会继续执行完毕，不会被中断。
这意味着：如果你设了 "02:00"–"06:00"，凌晨 5:59 启动的迁移可能到上午 8 点还在跑；而 6:01 进来的迁移请求会被排队，直到下一个窗口开启才启动。
- 窗口外
currentlyRunning: true仍可能出现——说明有迁移尚未结束 -
activeWindow: null表示全天候允许启动迁移，等价于没设窗口 - 删除窗口应调用
sh.setBalancerWindow(null)，不是传空对象{}或空字符串 - 窗口时间基于配置服务器副本集主节点的系统时钟，确保所有 config server 时间同步（NTP）
为什么 sh.status() 里看不到实时迁移队列和延迟
sh.status() 的 balancer 段只返回三个静态字段：enabled、currentlyRunning、lastSeen。它不反映待处理 chunk 数量、迁移积压、分片间 chunk 数偏差或网络延迟——这些得查其他地方。
如果 lastSeen 时间戳超过 1 小时，基本可判定迁移卡住。此时要立刻查：
-
config.migrationHistory集合，过滤status: "failed"的记录 -
mongos日志，搜索moveChunk+error或timeout -
config.chunks聚合统计：按shard分组计数，看最大最小差值是否远超阈值（默认 8 个 chunk） - 目标分片磁盘空间、网络连通性、writeConcern 是否满足（尤其当启用了
_secondaryThrottle: true）
关闭 Balancer 与禁用单集合 Balancing 的区别
全局停用 sh.stopBalancer() 会中止所有迁移，但已开始的迁移会完成；而 sh.disableBalancing("db.coll") 只让该集合退出均衡队列，不影响其他集合——两者用途完全不同，别混用。
典型误用场景：为规避备份不一致而停 Balancer，结果只对某个集合调用了 disableBalancing，其他集合仍在迁移，备份依然可能出问题。
- 备份前必须用
sh.stopBalancer()，并确认sh.isBalancerRunning()返回false -
sh.disableBalancing()适合长期倾斜的冷数据集合，或分片键设计不合理、易出 jumbo chunk 的集合 - 禁用单集合后，其 chunk 不再参与自动迁移，但手动
moveChunk仍可用 - MongoDB 5.0+ 支持
reshardCollection，对已禁用 Balancing 的集合重分片前需先enableBalancing
配置窗口本身不难，难的是理解它不控制“正在跑的任务”，只控制“新任务能不能开”。真正影响业务稳定性的，往往是窗口外残留的长耗时迁移、jumbo chunk 卡死、或 writeConcern 设置过高导致迁移慢——这些都藏在 sh.status() 看不见的地方。
