详解MongoDB分片集群平衡器状态监控及sh.status查看活动窗口

sh.status()中balancer部分仅显示是否启用、是否运行中、最近成功迁移时间；不反映待迁移chunk、队列状态、延迟或分布偏差，诊断需查config.migrationHistory、mongos日志及config.chunks聚合统计。

许多初次接触分片集群的开发者在看到sh.status()输出中的balancer部分时，往往误以为这就是平衡器的全貌。实际上，这里隐藏着不少细节与陷阱。今天我们就深入剖析，明确哪些信息可靠可用，哪些需要转向其他数据源去挖掘。

sh.status() 返回的 balancer 部分究竟提供了哪些信息

查看 sh.status() 输出里的 balancer 段，核心信息仅包含三要素：是否启用、是否正在运行、最近一次成功迁移的时间戳。它并不会告知你“下一步要迁移哪块 chunk”，也不会展示排队中的迁移任务——这些内容需要查询 config 数据库或查看 mongos 日志才能获取。

常见误区是将 "enabled": true 理解为“此刻正在进行数据迁移”，其实它仅仅表示平衡器开关已打开；而 "currentlyRunning": true 才表明有迁移任务正在执行（即便只有一条）。

• "enabled": false 代表平衡器被手动停止（通过 sh.stopBalancer()），即使集群严重数据倾斜也不会自动处理
• "currentlyRunning": true 但 "activeWindow": null，意味着没有设置活动窗口，平衡器全天候持续工作
• 若 "lastSeen": "..." 时间戳超过 1 小时未更新，大概率迁移过程出现卡住，需排查 config.migrationHistory 或 mongos 日志中的 moveChunk 错误

活动窗口（activeWindow）并非定时任务，而是一个白名单时间段

activeWindow 是平衡器允许执行迁移操作的时间范围，并非类似 cron 的定时调度机制。它仅控制迁移启动的时机，不会中断已在进行的迁移过程。一旦迁移开始，即便超出窗口设定的时间，也会继续完成。

配置方式是通过调用 sh.setBalancerWindow()，并传入 UTC 时间段（注意不是本地时区）：

sh.setBalancerWindow( { start: "22:00", stop: "06:00" } )

该配置存储在 config.settings 集合中，所有 mongos 实例共享。如果多个 mongos 同时执行该命令，后写入的会覆盖前写入的——没有合并逻辑。

• 时间格式必须严格为 "HH:MM"，不支持秒、时区缩写或 AM/PM
• 跨日区间（如 "22:00" 到 "06:00"）是合法的，内部按照 UTC 处理
• 删除窗口只需设置为 null：sh.setBalancerWindow(null)，不要使用空对象
• 修改后不会立即生效，下一个平衡周期（默认每 10 分钟检查一次）才会读取新配置

为什么 sh.status() 里看不到迁移延迟或 chunk 分布偏差

sh.status() 的 balancer 块本质上是状态快照，而非监控仪表盘。它不包含实时负载、延迟数值、chunk 数量差值等指标——这些需要自行计算获得。

例如，要判断集群是否失衡，不能仅依赖 "currentlyRunning": false，还需要检查各 shard 的 chunk 总数：

db.getSiblingDB("config").chunks.aggregate([
   { $group: { _id: "$shard", count: { $sum: 1 } } }
])

再结合 db.getSiblingDB("config").tags.find() 查看分片标签规则，才能确认是真正的数据倾斜还是策略导致的“假失衡”。

• 平衡器默认每 10 分钟触发一次检查，但实际迁移频率受 chunkSize、网络延迟、目标 shard 磁盘压力等因素影响，sh.status() 不会反映这些动态
• 如果某次 moveChunk 失败（例如目标 shard 写入已满），错误信息仅记录在 mongos 日志和 config.migrationHistory 中，sh.status() 里只会显示 "lastSeen" 时间停滞
• sh.status() 输出的 "migrationCount" 是历史累计值，并非当前队列长度，无法用于判断迁移任务的积压情况

停用平衡器时，sh.stopBalancer() 和直接修改 config.settings 效果不同

sh.stopBalancer() 提供安全停用流程：它首先等待当前正在进行的迁移完成，然后更新 config.settings 并广播给所有 mongos 实例。而直接手动 update config.settings 中的 balancer 文档，虽然会立即生效，但可能中断正在执行的迁移，导致数据不一致或锁残留。

恢复时同理：sh.startBalancer() 会校验集群健康状态（例如所有 shard 是否可达），而直接修改 "enabled": true 不做任何检查。

• 生产环境中停用平衡器务必使用 sh.stopBalancer()，不要绕过 shell 封装
• 停用期间新增的 chunk（如通过 bulk insert 操作）不会自动被切分，直到平衡器重启后才会参与均衡——这一点常被忽略
• 如果 sh.stopBalancer() 卡住超过 30 秒，大概率存在迁移阻塞，需要检查 config.locks 中 "_id": "balancer" 的 state 字段是否等于 2（表示被其他操作锁定）

平衡器的状态看似简单，但 sh.status() 隐藏了大量上下文依赖：时间窗口的 UTC 语义、迁移中断的边界条件、停用操作的原子性保障。若真要用它诊断问题，必须随时准备好翻阅 config.migrationHistory 和 mongos 日志。