我们正在尝试在相对较小的数据库上执行简单的MongoDump。
我们的步骤很简单:
出口
从目标计算机中删除现有数据库
导入目标计算机
MongoDump完美执行。
while(condition)
{
switch(anumber)
{
case 0:
//do something
continue;
case 1:
//do something
continue;
//and so on
}
Console.WriteLine("it's a message");
}
DB drop也是如此:
mongodump --out=/root/mongo-prod
另一方面,在调用mongoRestore后
mongo db_name --eval "db.dropDatabase()"
导入过程开始,并挂起3个特定的集合,并重复以下错误:
mongorestore --stopOnError --drop --db db_name /root/mongo-prod-{{ build }}/db_name/
*******这无限循环*******
p.s添加--repair到mongodump命令,在mongorestore上创建一个不同的错误:
no collection options to restore
restoring db_name.Collection4 from file /root/mongo-prod-31/db_name/Collection4.bson
file /root/mongo-prod-31/db_name/Collection4.bson is 56625 bytes
using 1 insertion workers
[########################] db_name.Collection1 106.7 KB/106.7 KB (100.0%)
[########################] db_name.Collection2 63.5 KB/63.5 KB (100.0%)
[######..................] db_name.Collection3 6.7 MB/25.9 MB (25.8%)
[########################] db_name.Collection4 55.3 KB/55.3 KB (100.0%)
[########################] db_name.Collection1 106.7 KB/106.7 KB (100.0%)
[########################] db_name.Collection2 63.5 KB/63.5 KB (100.0%)
[######..................] db_name.Collection3 6.7 MB/25.9 MB (25.8%)
[########################] db_name.Collection4 55.3 KB/55.3 KB (100.0%)
答案 0 :(得分:7)
显然,问题与MongoDB 写问题有关。从MongoDB文档(版本3.2):
写入问题描述了MongoDB请求的确认级别,用于对独立mongod或副本集或分片集群的写入操作。
在副本集配置中,此选项定义在认为成功之前需要写入多少副本写操作。
mongorestore
实用程序将默认写入关注设置为 多数 。这样的值需要确认写操作已经传播到大多数投票节点,包括主节点。如果你的副本集(退出!)成员的次数减少了1/2,那么mongorestore将永远挂起,等待大多数成员的确认。来自文档:
如果未指定wtimeout选项且写入关注程度无法实现,则写入操作将无限期阻止。
如果仍需要执行数据库还原,只需在--writeConcern '{w:0}'
命令中指定mongorestore
即可。这将禁用对当前mongo连接的写入操作的确认,并且您将能够还原数据库。
以下是文档的链接: https://docs.mongodb.com/v3.2/reference/write-concern
P.S。最新的MongoDB版本3.4也是可以接受的。
答案 1 :(得分:4)
我在副本集上遇到了同样的问题,我试图在主节点上进行恢复,而辅助节点(在副本集中)已经关闭。我开始中学,然后开始成功恢复。
答案 2 :(得分:1)
我遇到了类似的问题。我的数据库有一个巨大的集合 - 几百GB大。 Mongorestore在主服务器上完成,索引已经构建,因此我尝试为另一个数据库运行mongorestore。这个mongorestore的例子陷入了1%的困境。当我查看二级日志时,它仍在构建索引。在为其他数据库运行mongorestore之前,我不得不等待在辅助服务器上重建索引
答案 3 :(得分:0)
我有同样的问题,可以通过扩大wiredTiger的缓存来解决它:
#cat /etc/mongod.conf
..
wiredTiger:
engineConfig:
cacheSizeGB: 2
..
(之前已设为1GB)
HTH
答案 4 :(得分:0)
在mongo版本3.2.8上有同样的问题。
已更新至mongo 3.4.9
,一切正常。
答案 5 :(得分:0)
我刚刚花了一个小时:
从存档中读取
--archive=/backup...
忽略存档参数并等待stdin
--archive /backup
似乎参数可以使用arg值或arg = value,但不能存档...