Question

我做了一个mongorestore mongodump的{{1}}：

mongorestore -v --drop --gzip --db bigdata /Volumes/Lacie2TB/backup/mongo20170909/bigdata/

但它继续前进。我离开了，因为我想我是否只是＆＃39;现在关闭它，我的（重要）数据将被破坏。检查百分比：

2017-09-10T14:45:58.385+0200    [########################]  bigdata.logs.sets.log  851.8 GB/85.2 GB  (999.4%)
2017-09-10T14:46:01.382+0200    [########################]  bigdata.logs.sets.log  852.1 GB/85.2 GB  (999.7%)
2017-09-10T14:46:04.381+0200    [########################]  bigdata.logs.sets.log  852.4 GB/85.2 GB  (1000.0%)

它继续前进！

请注意，其他集合已完成。只有这一个超过100％。我不明白。

这是Mac OSX上的mongo 3.2.7。

导入的数据量显然存在问题，因为甚至没有那么多的磁盘空间。

$ df -h
Filesystem      Size   Used  Avail Capacity   iused     ifree %iused Mounted on
/dev/disk3     477Gi  262Gi  214Gi    56%  68749708  56193210   55%   /

使用的磁盘空间可能是正确的，因为gzipped备份大约为200GB。我不知道这是否会导致WiredTiger数据库上的snappy压缩数据量相同。

但是，日志会一直显示插入内容：

2017-09-10T16:20:18.986+0200 I COMMAND  [conn9] command bigdata.logs.sets.log command: insert { insert: "logs.sets.log", documents: 20, writeConcern: { getLastError: 1, w: 1 }, ordered: false } ninserted:20 keyUpdates:0 writeConflicts:0 numYields:0 reslen:40 locks:{ Global: { acquireCount: { r: 19, w: 19 } }, Database: { acquireCount: { w: 19 } }, Collection: { acquireCount: { w: 19 } } } protocol:op_query 245ms
2017-09-10T16:20:19.930+0200 I COMMAND  [conn9] command bigdata.logs.sets.log command: insert { insert: "logs.sets.log", documents: 23, writeConcern: { getLastError: 1, w: 1 }, ordered: false } ninserted:23 keyUpdates:0 writeConflicts:0 numYields:0 reslen:40 locks:{ Global: { acquireCount: { r: 19, w: 19 } }, Database: { acquireCount: { w: 19 } }, Collection: { acquireCount: { w: 19 } } } protocol:op_query 190ms

更新

磁盘空间仍在消耗中。这大概是2个小时之后，大约30 GB之后：

$ df -h
Filesystem      Size   Used  Avail Capacity   iused     ifree %iused  Mounted on
/dev/disk3     477Gi  290Gi  186Gi    61%  76211558  48731360   61%   /

问题是：进度指示器中是否存在错误，或者是否存在某种不断插入相同文档的循环？

更新

结束了。

2017-09-10T19:35:52.268+0200    [########################]  bigdata.logs.sets.log  1604.0 GB/85.2 GB  (1881.8%)
2017-09-10T19:35:52.268+0200    restoring indexes for collection bigdata.logs.sets.log from metadata
2017-09-10T20:16:51.882+0200    finished restoring bigdata.logs.sets.log (3573548 documents)
2017-09-10T20:16:51.882+0200    done

604.0 GB / 85.2 GB（1881.8％）

有趣。：）

Answer 1

看起来类似于这个错误：https://jira.mongodb.org/browse/TOOLS-1579

似乎有一个向后移植到3.5和3.4的修复程序。修复程序可能不会向后移植到3.2。我认为问题可能与使用gzip和/或snappy压缩有关。

我的mongoimport跑到无限

更新

更新

1 个答案: