13

我们正在尝试在一个相对较小的数据库上做一个简单的 MongoDump。

我们的步骤很简单：

  1. 出口

  2. 从目标机器中删除现有数据库

  3. 在目标机器上导入

MongoDump 完美执行。

mongodump --out=/root/mongo-prod

DB drop 也是如此：

mongo db_name --eval "db.dropDatabase()"

另一方面，调用 mongoRestore 后

mongorestore --stopOnError --drop --db db_name /root/mongo-prod-{{ build }}/db_name/

导入过程开始，并挂在 3 个特定的集合上，并重复出现以下错误：

    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%)

******* 这无限循环 *******

ps 将 --repair 添加到 mongodump 命令，会在 mongorestore 上创建不同的错误：

  Failed: restore error: db_name.Collection1: error restoring from /root/mongo-prod-33/db_name/Collection1.bson: insertion error: E11000 duplicate key error index: db_name.Collection1.$_id_ dup key: { : ObjectId('5651802de4b0293285f7f508') }
4

6 回答 6

29

我只花了一个小时：

从存档中读取

--archive=/backup...

忽略归档参数并等待标准输入

--archive /backup

似乎参数与 arg 值或 arg=value 一起使用，只是不能存档......

于 2019-03-10T22:16:22.193 回答
11

显然，问题与 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

PS 最新的 MongoDB 版本 3.4 也可以接受。

于 2016-12-27T21:10:37.950 回答
5

我在副本集上遇到了同样的问题，我试图在主节点（在副本集中）关闭时恢复主节点。我开始辅助，然后它开始成功恢复。

于 2016-02-08T11:07:21.630 回答
2

我遇到了类似的问题。我的数据库有一个庞大的集合——几百 GB。Mongorestore 在主数据库上完成，建立了索引，所以我尝试为另一个数据库运行 mongorestore。这个 mongorestore 实例卡在 1%。当我查看辅助日志时，它仍在构建索引。在为其他数据库运行 mongorestore 之前，我必须等待在辅助数据库上重建索引

于 2016-05-20T23:24:44.287 回答
1

在 mongo 版本 3.2.8 上有同样的问题。

更新到mongo 3.4.9一切正常。

于 2017-09-25T04:46:40.093 回答
0

我有同样的问题，可以通过扩大wiredTiger的缓存来解决：

# 猫 /etc/mongod.conf

..
  wiredTiger:
    engineConfig:
      cacheSizeGB: 2
..

（以前设置为 1GB）

高温高压

于 2016-01-11T17:23:01.223 回答