情况如下：
有一个块，其分片范围为[10001, 100030]，但目前只有一个密钥(e.g. 10001)有数据，密钥范围[10002, 10030]只是空的，夹头数据超出8M，然后我们将当前的吸盘大小设置为8M。
在我们填充键范围[10002, 10030]中的数据之后，这个块开始分裂，并停在像这个`[10001,10003]这样的键范围内，它有两个键，我们只是想知道这是不是没关系。
从官方网站上的文档中我们认为该块可能不包含多于一个密钥。
那么，请你帮我们确认这是否合适？
我们想要的是尽可能多地拆分块，以确保数据平衡。
答案 0 :(得分：0)
有一个名为jumbo chunks的概念。每个超过其指定大小或文档数量超过最大配置数量的块都被视为巨型块。
由于当达到大约一半的块大小时，MongoDB通常会分割一个块，所以我将Jumbo块作为集群中存在相当错误的标志。
jumbo chunk的最可能原因是一段时间内没有一个或多个配置服务器可用。
需要将元数据更新写入所有三个配置服务器（它们不构建副本集），如果其中一个配置服务器关闭，则无法进行元数据更新。块拆分和迁移都需要元数据更新。因此，当一个配置服务器关闭时，一个块不能及早拆分，它的大小会增加，最终变成一个巨大的块。
即使所有三个配置服务器都可用，Jumbo块也不会自动拆分。原因是......好吧，恕我直言，MongoDB在这里稍微保存一下。而Jumbo的大块也没有被移动。其原因是相当明显的 - 移动数据理论上可以具有任何大小＆gt; 16MB只是一个成本太高的操作。
继续自担风险！你已经收到警告了！
由于您可以识别巨型块，因此它们非常容易处理。 只需识别块的关键范围并在
中使用它sh.splitFind("database.collection", query)
这将识别有问题的碎片并将其分成两半，这非常重要。请阅读Split Chunks in a Sharded Cluster并确保在尝试手动拆分块之前了解所有内容及其含义。