均衡器的用途

均衡器是一个后台线程，运行于配置服务器(config server)副本集的主节点。它定期检查分片中块(chunks)和数据的分布情况。如果达到某些迁移阈值，均衡器就会决定将块从一个分片迁移到另一个分片。其主要目标是在所有分片中拥有大致相同的数据量。

在繁忙的集群中，迁移的成本可能很高。每次迁移都需要从源分片读取大量文档，然后写入目标分片。因此，有一个限制：给定一个分片对(shard pair)，每次只能移动一个分片。因此，在 N 个分片集群中，最多只能同时迁移 N/2 个分片。

如果你在集合中定义的所有分块键都是最优的，那么均衡器管理的迁移量应该是最小的，或者最终接近于零。如果分块键不理想或集合设计不合理，就会导致大量昂贵的迁移，从而拖慢整个集群的运行速度。更糟糕的情况是，均衡器无法运行所有需要的迁移，这样就会导致集群不平衡，无法管理。

如果没有定义好分片键，你也可以改变主意，创建新的分片键。遗憾的是，对大型数据集重新分片的成本很高，应尽量避免。

均衡器的策略

均衡器在开发之初就设定了当分片达到特定的迁移阈值时，对分片中的某一块进行迁移。这些阈值适用于拥有最多数据集数据块的分片与拥有最少数据集数据块的分片之间的数据块数量差异。

均衡器会持续地将块从源分片移动到块数较少的目标分片，确保数据可用于读写。这个简单的逻辑有助于在所有分片中保持大致相同的块数。

下表显示了迁移阈值。

遗憾的是，这种逻辑有一些局限性。在许多使用案例中，有可能拥有不同数据量的数据块。有些数据块可能是满的，接近允许的最大数据块大小，而另一些数据块可能接近空。这主要取决于你在集合中定义的分片键。如果你的分块键不够理想，不能提供均匀分布的值，那么就有可能出现这种情况。

均衡器进行的迁移可以起到帮助作用，但要记住迁移的成本很高，而且在某些情况下执行迁移的速度不足以确保数据的均匀分布。分片之间的数据差异可能会持续扩大。

从 MongoDB 6.0 版开始，均衡器逻辑发生了重要变化。策略不再计算分片中块的数量，而是计算分片中数据的实际大小。迁移阈值仍然有效，但现在无论有多少块，它们都基于数据的实际大小。

如果一个数据集的分片之间的数据差异小于该数据集配置范围大小的三倍，那么该数据集就被认为是平衡的。对于 128 MB 的默认范围大小，只有当同一数据集的两个分片之间的数据大小差异至少达到 384 MB 时，才会发生迁移。该阈值受块的最大大小影响。设置不同的块大小也会改变阈值，计算公式仍然为块大小的三倍。

新策略有助于获得更均衡的群集，即使在分片建并非最佳的情况下也是如此。不过，请记住，非常糟糕的分片键会导致集群非常不稳定。新的均衡器策略并不神奇，无法帮助解决糟糕的情况。

新的自动合并(Automerger)功能

合并块一直都可以手动完成。有了 mergeChunks 管理命令，就可以合并同一分片中连续的数据块。合并可以避免有太多数据量过少的数据块。更多的块也会使配置数据库变大，降低效率。从 7.0 版开始，均衡器内部部署了新的自动合并功能。也可以使用 mergeChunks 命令进行手动合并。

Automerger 作为配置服务器副本集主节点中常规 Balancer 线程的一部分运行。

每次执行时，自动合并器都会检查同一集合中符合特定合并要求的数据块，并自动将它们合并。可以同时合并两个或多个数据块。这里列出了可合并性要求，所有要求都必须满足：

·数据块必须位于同一分片中

·它们不是巨型块( jumbo chunks)

·它们的历史记录可以在不中断事务和快照读取的情况下被安全清除

如果需要，可以禁用或配置 Automerger，使其仅在均衡器窗口期间运行。可以通过mongosh客户端进行开启或者禁用。比如:

开启

sh.enableAutoMerger( <namespace> )

禁用

sh.disableAutoMerger( <namespace> ) 

也可以使用以下管理命令：

db.adminCommand(
  {
    configureCollectionBalancing: "<db>.<collection>",
    chunkSize: <num>,
    defragmentCollection: <bool>
    enableAutoMerger: <bool>
  }
)

Automerger 是能帮助你自动优化集群，不再需要考虑手动合并块的问题。在文档中，你可以获得更多详细信息： https://www.mongodb.com/docs/manual/core/automerger-concept/

总结

7.0 中引入的 Automerger 和 6.0 中的新 Balancer 策略可以简化管理任务，并有助于获得更稳定、更可靠的分片集群。

MongoDB 发展非常迅速。每年都会发布一个新的主版本，而旧版本在短短几年内就会失去支持。如果还在使用旧版本，建议尽快升级到 7.0。5.0 版本的生命周期将于 2024 年 10 月结束。6.0 版本将于 2025 年 7 月到期。