使用mongorestore将数据还原到分片群集时的预期平衡行为

Question

我注意到当通过mongos将mongorestore的数据恢复到分片群集时，所有记录最初都保存到主要分片（集合）中，只有平衡器进程移动这些块，这是一个相对较慢的过程，所以在恢复后我有类似的情况：

chunks:
    rs_shard-1  28
    rs_shard-2  29
    rs_shard-4  27
    rs_shard-3  644

我在mongodb / mongos日志文件中没有任何错误。

我不确定，但我认为过去的数据是以一种已经平衡的方式恢复的。现在我使用的是2.4.6版本。有人可以确认预期的行为是什么吗？

Answer 1

以下是imho发生的事情：

恢复数据时，分配给每个分片的块的初始范围。数据由mongorestore插入，无需等待来自mongos的任何响应，而不是说碎片，从而导致文档的相对快速插入。我假设您有一个单调增加的分片键，例如ObjectId。现在发生的事情是，在块区域的初始分配期间，已经为一个分片分配了从X到无限的范围（在mongoland中称为“maxKey”）。此范围内的文档将在该分片上创建，从而导致大量的块拆分以及该服务器上的块数量不断增加。块分割将触发平衡器轮，但由于新文档的插入比块迁移更快，因此块的数量将比平衡器减少更快。

所以我要做的是检查分片键。我很确定它是单调增加的。这不仅在恢复备份时很糟糕，而且在生产使用中也是如此。请参阅MongoDB文档中的shard key documentation和Considerations for Selecting Shard Keys。

一些额外的说明。 mongodump实用程序专为小型数据库而设计，例如分片集群的配置数据库。您的数据库大小约为46.5GB，并不是很小。我宁愿在每个单独的分片上使用文件系统快照，使用cronjob进行同步。如果确实需要时间点恢复，您仍然可以在快照文件上以直接文件访问模式使用mongodump来创建转储并使用--oplogLimit恢复这些转储选项。除了执行时间点恢复的能力之外，mongodump的使用没有优于获取文件系统快照的优势，但缺点是您必须停止平衡器以获得一致的备份并锁定整个备份过程中的数据库，以便有一个真正的时间点恢复选项。