mongodb - 使用 mongorestore 将数据恢复到分片集群时的预期平衡行为

Question

我注意到，当通过 mongos 使用 mongorestore 将数据恢复到分片集群时，所有记录最初都保存到主分片(集合的)，只有平衡器进程移动这些 block ，这是一个相对缓慢的过程，所以在恢复后我有类似的情况:

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

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

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

Answer 1

恕我直言，这是发生了什么:

恢复数据时，分配给每个分片的 block 有初始范围。数据由 mongorestore 插入，无需等待 mongos 的任何响应，更不用说分片了，因此文档的插入速度相对较快。我假设您有一个单调递增的分片键，例如 ObjectId。现在发生的事情是，在 block 范围的初始分配期间，一个分片被分配了从 X 到无限的范围(在 mongoland 中称为“maxKey”)。此范围内的文档将在该分片上创建，导致大量 block 拆分和该服务器上的 block 数量增加。 block 拆分将触发平衡器回合，但由于新文档的插入比 block 迁移更快， block 数量的增加速度将快于平衡器减少它的速度。

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

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