MongoDB分片集合未重新平衡
我们有一个相对简单的分片MongoDB设置：4个分片，每个分片是一个副本集，至少有3个成员。每个集合都由从大量文件加载的数据组成;每个文件都被赋予一个单调递增的ID，并且根据ID的哈希完成分片。
我们的大部分产品都在按预期工作。然而，我有一个集合似乎没有正确地将块分布到各个碎片上。在创建索引之前，集合加载了大约30GB的数据，并且进行了分片，但是据我所知，这并不重要。以下是该集合的统计数据:
mongos> db.mycollection.stats()
{
"sharded" : true,
"ns" : "prod.mycollection",
"count" : 53304954,
"numExtents" : 37,
"size" : 35871987376,
"storageSize" : 38563958544,
"totalIndexSize" : 8955712416,
"indexSizes" : {
"_id_" : 1581720784,
"customer_code_1" : 1293148864,
"job_id_1_customer_code_1" : 1800853936,
"job_id_hashed" : 3365576816,
"network_code_1" : 914412016
},
"avgObjSize" : 672.9578525853339,
"nindexes" : 5,
"nchunks" : 105,
"shards" : {
"rs0" : {
"ns" : "prod.mycollection",
"count" : 53304954,
"size" : 35871987376,
"avgObjSize" : 672.9578525853339,
"storageSize" : 38563958544,
"numExtents" : 37,
"nindexes" : 5,
"lastExtentSize" : 2146426864,
"paddingFactor" : 1.0000000000050822,
"systemFlags" : 0,
"userFlags" : 0,
"totalIndexSize" : 8955712416,
"indexSizes" : {
"_id_" : 1581720784,
"job_id_1_customer_code_1" : 1800853936,
"customer_code_1" : 1293148864,
"network_code_1" : 914412016,
"job_id_hashed" : 3365576816
},
"ok" : 1
}
},
"ok" : 1
}
这个集合的sh.status（）：
prod.mycollection
shard key: { "job_id" : "hashed" }
chunks:
rs0 105
too many chunks to print, use verbose if you want to force print
我是否遗漏了为什么这个集合只会分发给rs0？有没有办法强制重新平衡？我执行了相同的步骤来分片其他集合，并且它们正确分布了自己。以下是成功分片的集合的统计信息：
mongos> db.myshardedcollection.stats()
{
"sharded" : true,
"ns" : "prod.myshardedcollection",
"count" : 5112395,
"numExtents" : 71,
"size" : 4004895600,
"storageSize" : 8009994240,
"totalIndexSize" : 881577200,
"indexSizes" : {
"_id_" : 250700688,
"customer_code_1" : 126278320,
"job_id_1_customer_code_1" : 257445888,
"job_id_hashed" : 247152304
},
"avgObjSize" : 783.3697513591966,
"nindexes" : 4,
"nchunks" : 102,
"shards" : {
"rs0" : {
"ns" : "prod.myshardedcollection",
"count" : 1284540,
"size" : 969459424,
"avgObjSize" : 754.7133012595949,
"storageSize" : 4707762176,
"numExtents" : 21,
"nindexes" : 4,
"lastExtentSize" : 1229475840,
"paddingFactor" : 1.0000000000000746,
"systemFlags" : 0,
"userFlags" : 0,
"totalIndexSize" : 190549856,
"indexSizes" : {
"_id_" : 37928464,
"job_id_1_customer_code_1" : 39825296,
"customer_code_1" : 33734176,
"job_id_hashed" : 79061920
},
"ok" : 1
},
"rs1" : {
"ns" : "prod.myshardedcollection",
"count" : 1287243,
"size" : 1035438960,
"avgObjSize" : 804.384999568846,
"storageSize" : 1178923008,
"numExtents" : 17,
"nindexes" : 4,
"lastExtentSize" : 313208832,
"paddingFactor" : 1,
"systemFlags" : 0,
"userFlags" : 0,
"totalIndexSize" : 222681536,
"indexSizes" : {
"_id_" : 67787216,
"job_id_1_customer_code_1" : 67345712,
"customer_code_1" : 30169440,
"job_id_hashed" : 57379168
},
"ok" : 1
},
"rs2" : {
"ns" : "prod.myshardedcollection",
"count" : 1131411,
"size" : 912549232,
"avgObjSize" : 806.5585644827565,
"storageSize" : 944386048,
"numExtents" : 16,
"nindexes" : 4,
"lastExtentSize" : 253087744,
"paddingFactor" : 1,
"systemFlags" : 0,
"userFlags" : 0,
"totalIndexSize" : 213009328,
"indexSizes" : {
"_id_" : 64999200,
"job_id_1_customer_code_1" : 67836272,
"customer_code_1" : 26522944,
"job_id_hashed" : 53650912
},
"ok" : 1
},
"rs3" : {
"ns" : "prod.myshardedcollection",
"count" : 1409201,
"size" : 1087447984,
"avgObjSize" : 771.6769885914075,
"storageSize" : 1178923008,
"numExtents" : 17,
"nindexes" : 4,
"lastExtentSize" : 313208832,
"paddingFactor" : 1,
"systemFlags" : 0,
"userFlags" : 0,
"totalIndexSize" : 255336480,
"indexSizes" : {
"_id_" : 79985808,
"job_id_1_customer_code_1" : 82438608,
"customer_code_1" : 35851760,
"job_id_hashed" : 57060304
},
"ok" : 1
}
},
"ok" : 1
}
sh.status()用于正确分片的集合:
prod.myshardedcollection
shard key: { "job_id" : "hashed" }
chunks:
rs2 25
rs1 26
rs3 25
rs0 26
too many chunks to print, use verbose if you want to force print
共有1个答案
在MongoDB中，当你进入一个分片系统时，你看不到任何平衡，这可能是几件事情之一。
>
您可能没有足够的数据触发平衡。这绝对不是您的情况，但有些人可能没有意识到，由于默认块大小为64MB，可能需要一段时间才能插入数据，然后才有足够的数据将其中的一些数据拆分并平衡到其他块。
平衡器可能没有运行-因为您的其他集合正在得到平衡，所以在您的情况下不太可能实现平衡，除非在平衡器因某种原因停止后最后对该集合进行了分片。
无法移动集合中的块。当碎片密钥粒度不够大，无法将数据分割成足够小的块时，可能会发生这种情况。事实证明，这是您的情况，因为您的分片密钥对于这么大的一个集合来说粒度不够-您有105个块（可能对应于唯一job_id值的数量）和超过30GB的数据。当块太大并且平衡器无法移动它们时，它会将它们标记为“巨型”（这样它就不会旋转轮子试图迁移它们）。
如何从分片键的错误选择中恢复？通常，更改分片键非常痛苦 - 由于分片键是不可变的，因此您必须执行相当于完整数据迁移的操作才能将其放入具有另一个分片键的集合中。但是，在你的例子中，集合仍然全部在一个分片上，因此“取消分片”集合并使用新的分片键重新分片它应该相对容易。由于job_ids的数量相对较少，我建议使用常规索引对job_id，customer_code进行分片，因为您可能会对此进行查询，并且我猜它总是在文档创建时设置的。
-
我使用Spring Boot和Spring Data MongoDB与底层分片MongoDB集群进行接口。我的Spring Boot应用程序通过路由器访问集群。 使用Spring Data MongoDB，可以通过指定对象持久化到的集合，或者默认为类名（第一个字母小写）。这些藏品不需要预先存在；它们可以在运行时创建。 要在MongoDB中分片集合，您需要 1-在数据库上启用分片： 2-在分片数据库
-
我在数据库中有一个集合“documentDev ”,其切分关键字为“dNumber”样本文档: 如果我尝试使用任何查询工具更新这个文档，比如- 它会正确更新文档。但是如果我确实使用了Spring boot的mongorepository命令，如DocumentRepo.save（Object），它会引发异常 由以下原因引起：com.mongodb.MongoCommandException：命令失
-
我在localhost上设置了一个分片的mongo db环境，有3个配置服务器、2个分片的mongo实例和一个mongos。 集群启动后，我运行以下命令序列: 我启用数据库进行分片，并创建一个索引等。 以上所有操作的结果都是成功的。 但是一旦我做到了：db.foo.stats（） 我看到所有的数据都在一个分片中结束，而没有被分发。和运行 生产： 然而，有趣的是，如果我从一个空白集合开始，并在向其中
-
我正在尝试重命名/删除一个 Mongo 集合，我无意中放了一个 .（点） 在数据库集合名称的末尾，因此集合名称如下所示： 收藏品名称。 我无法找到一种方法来使用包含点号的集合名称来删除或重命名集合，而不会返回错误。 任何建议这是否是可能的。
-
我正在使用MongoDB 2.6标准。我已经成功地创建了多个集合，插入数据，查询数据等。在Mongo shell内部工作良好，以及从使用MongoSkin的NodeJS应用程序。到目前为止，一切都很好。现在我需要使用第三方工具（D2RQ）来访问数据。似乎D2RQ使用_schema集合来获取集合名称，列名，数据类型等。D2RQ适用于其中三个集合，因为集合在MongoDB中_schema。第四个集合不
-
主要内容：MongoDB 中的分片,分片实例分片是跨多台机器存储数据的过程，它是 MongoDB 满足数据增长需求的方法。随着数据的不断增加，单台机器可能不足以存储全部数据，也无法提供足够的读写吞吐量。通过分片，您可以添加更多计算机来满足数据增长和读/写操作的需求。 为什么要分片？ 在复制中，所有写操作都将转到主节点； 对延迟敏感的查询仍会转到主查询； 单个副本集限制为 12 个节点； 当活动数据集很大时，会出现内存不足； 本地磁盘不够大；