mongodb - 如何加速 Mongodump,转储未完成

标签 mongodb mongodump

在尝试使用来自大约 50 亿的数据库的查询运行数据库转储时,进度条时间似乎表明此转储不会在任何合理的时间(100 多天)内完成。大约 22 小时后,查询似乎以 0% 结束后也卡住了 - 后面的行是 metadata.json 行。

转储行是:

mongodump -h myHost -d myDatabase -c mycollection --query "{'cr' : {\$gte: new Date(1388534400000)}, \$or: [ { 'tln': { \$lte: 0., \$gte: -100.}, 'tlt': { \$lte: 100, \$gte: 0} }, { 'pln': { \$lte: 0., \$gte: -100.}, 'plt': { \$lte: 100, \$gte: 0} } ] }"

我的最后几行输出是(因为我还不能发布图片而打字。)

[timestamp] Collection File Writing Progress: 10214400/5066505869 0% (objects)
[timestamp] Collection File Writing Progress: 10225100/5066505869 0% (objects)
[timestamp] 10228391 objects
[timestamp] Metadata for database.collection to dump/database/collection.metadata.json

有什么想法可以帮助提高性能,或者为什么需要这么长时间?

最佳答案

我刚遇到这个问题,问题是 mongodump 基本上不是很聪明。它正在遍历 _id 索引,这可能意味着大量的随机磁盘访问。对我来说,转储多个集合时,mongodump 只是由于游标超时而崩溃。

这里也描述了这个问题:https://jira.mongodb.org/browse/TOOLS-845 .但是,这并没有真正提供“按设计工作”的高分辨率部分。索引可能有一些有趣的地方,但我认为就我而言,它只是一个足够大的集合,以至于磁盘访问量对于我可怜的小 Mac Mini 来说是一项非常艰巨的工作。

一个解决方案?关闭写入,然后使用 --forceTableScan,它会按顺序传递数据,如果您使用的是自定义 ,这可能比使用 _id 索引更快code>_id 字段(我是)。

文档有点粗略,但它看起来好像正常的 mongodump 行为可能是使用快照遍历 _id 索引,然后按查询进行过滤。换句话说,它可能以 _id 的顺序遍历所有 50 亿条记录,而不是存储数据的顺序,即随机地完成查询。因此,您最好构建一个从真实索引读取并直接写入的工具。

对我来说,--forceTableScan 就足够了,这意味着 (a) 它实际上成功完成,并且 (b) 它快一个数量级或更多。

关于mongodb - 如何加速 Mongodump,转储未完成,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/28017653/

相关文章:

javascript - 在 Mongo View 中处理数学计算

javascript - MongoDB:通过数组中的一个objectId查找

javascript - Mongodb 查找不返回数组

MongoDB - 备份和恢复用户和角色

arrays - 查询对象与数组

javascript - 如何 react 性地在 meteor 中运行一个函数?

mongodb - 如何将 mongodump 用于 1 个集合

mongodb - 虚拟机上的 mongodump 文件损坏

MongoDB 远程备份和恢复

mongodb - mongorestore 错误失败 : EOF when restore DB from dump. gz