2

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

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

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

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

4

1 回答 1

1

这是发生了什么恕我直言：

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

所以我要做的是检查分片键。我很确定它是单调递增的。这不仅在恢复备份时很糟糕，而且在生产使用中也是如此。请参阅MongoDB 文档中的分片键文档和选择分片键的注意事项。

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

于 2014-08-03T16:04:34.483 回答