mongorestore 无法 copy/clone 现有数据库到新数据库
mongorestore fails to copy/clone an existing database to a new one
我在 Windows 10 Pro 上 运行 的默认位置安装了 MongoDB 版本 5.0.7。我有一个名为 mydb 的数据库,其中包含一个名为 products 的 collection。我想将 mydb 数据库复制到一个名为 newdb 的新数据库中。为此,我正在尝试使用 mongodump
和 mongorestore
命令,如 here 所述。这样做时,尽管 mongodump
正在执行并正确创建转储文件,但 mongorestore
命令每次都会失败,生成 重复键错误.
我用来将 mydb 数据库转储到存档的命令:
mongodump --archive="mongodump-mydb" --db=mydb
我用来将数据库从转储恢复到新数据库的命令:
mongorestore --archive="mongodump-mydb" --nsFrom='mydb.*' --nsTo='newdb.*'
我得到的错误信息:
2022-04-17T19:09:04.136+0530 preparing collections to restore from
2022-04-17T19:09:04.146+0530 reading metadata for mydb.products from archive 'mongodump-mydb'
2022-04-17T19:09:04.150+0530 restoring to existing collection mydb.products without dropping
2022-04-17T19:09:04.157+0530 restoring mydb.products from archive 'mongodump-mydb'
2022-04-17T19:09:04.209+0530 continuing through error: E11000 duplicate key error collection: mydb.products index: _id_ dup key: { _id: ObjectId('625974fe025923931b6e5e7f') }
2022-04-17T19:09:04.211+0530 continuing through error: E11000 duplicate key error collection: mydb.products index: _id_ dup key: { _id: ObjectId('62597508025923931b6e5e80') }
2022-04-17T19:09:04.211+0530 continuing through error: E11000 duplicate key error collection: mydb.products index: _id_ dup key: { _id: ObjectId('62597508025923931b6e5e81') }
2022-04-17T19:09:04.211+0530 finished restoring mydb.products (0 documents, 3 failures)
2022-04-17T19:09:04.211+0530 no indexes to restore for collection mydb.products
2022-04-17T19:09:04.211+0530 0 document(s) restored successfully. 3 document(s) failed to restore.
令人惊讶的是,它似乎恢复了 mydb 数据库而不是 newdb 中的 collection 产品。由于 mydb 已经包含产品 collection,其中包含具有唯一 ID 的文档行,因此它正在创建一个冲突,生成 重复键错误。
作为替代方案,在执行 mongorestore
时,我将新数据库的名称放在 --nsFrom
和 --nsTo
参数中以检查它是否有所不同:
mongorestore --archive="mongodump-mydb" --nsFrom='newdb.*' --nsTo='newdb.*'
然而,它产生了同样的错误。
不知何故,mongo 似乎完全忽略了新的数据库参数。为什么会发生这种情况,我该如何解决这个问题?因为,将现有数据从数据库复制到新数据库是我项目的常见需求,如果我无法从转储中恢复我的数据,那么只需要一次崩溃就可以永远丢失我的记录。所以请帮我解决这个问题。
此致
找到原因了。问题在于在传递 --nsFrom
和 --nsTo
参数的值时使用单引号。在这样做的同时,在某些环境中,mongo 继续将转储恢复到现有数据库而不是新数据库,从而在现有数据和正在恢复的数据之间造成冲突,从而产生“重复键错误”。当你遇到这种情况时,要么使用双引号来传递 --nsFrom
和 --nsTo
参数的值,要么根本不使用任何引号。
这显然是 MongoDB 服务器系统或其语法中的错误。 MongoDB开发团队必须注意这一点,并在下次更新中纠正它。
我在 Windows 10 Pro 上 运行 的默认位置安装了 MongoDB 版本 5.0.7。我有一个名为 mydb 的数据库,其中包含一个名为 products 的 collection。我想将 mydb 数据库复制到一个名为 newdb 的新数据库中。为此,我正在尝试使用 mongodump
和 mongorestore
命令,如 here 所述。这样做时,尽管 mongodump
正在执行并正确创建转储文件,但 mongorestore
命令每次都会失败,生成 重复键错误.
我用来将 mydb 数据库转储到存档的命令:
mongodump --archive="mongodump-mydb" --db=mydb
我用来将数据库从转储恢复到新数据库的命令:
mongorestore --archive="mongodump-mydb" --nsFrom='mydb.*' --nsTo='newdb.*'
我得到的错误信息:
2022-04-17T19:09:04.136+0530 preparing collections to restore from
2022-04-17T19:09:04.146+0530 reading metadata for mydb.products from archive 'mongodump-mydb'
2022-04-17T19:09:04.150+0530 restoring to existing collection mydb.products without dropping
2022-04-17T19:09:04.157+0530 restoring mydb.products from archive 'mongodump-mydb'
2022-04-17T19:09:04.209+0530 continuing through error: E11000 duplicate key error collection: mydb.products index: _id_ dup key: { _id: ObjectId('625974fe025923931b6e5e7f') }
2022-04-17T19:09:04.211+0530 continuing through error: E11000 duplicate key error collection: mydb.products index: _id_ dup key: { _id: ObjectId('62597508025923931b6e5e80') }
2022-04-17T19:09:04.211+0530 continuing through error: E11000 duplicate key error collection: mydb.products index: _id_ dup key: { _id: ObjectId('62597508025923931b6e5e81') }
2022-04-17T19:09:04.211+0530 finished restoring mydb.products (0 documents, 3 failures)
2022-04-17T19:09:04.211+0530 no indexes to restore for collection mydb.products
2022-04-17T19:09:04.211+0530 0 document(s) restored successfully. 3 document(s) failed to restore.
令人惊讶的是,它似乎恢复了 mydb 数据库而不是 newdb 中的 collection 产品。由于 mydb 已经包含产品 collection,其中包含具有唯一 ID 的文档行,因此它正在创建一个冲突,生成 重复键错误。
作为替代方案,在执行 mongorestore
时,我将新数据库的名称放在 --nsFrom
和 --nsTo
参数中以检查它是否有所不同:
mongorestore --archive="mongodump-mydb" --nsFrom='newdb.*' --nsTo='newdb.*'
然而,它产生了同样的错误。
不知何故,mongo 似乎完全忽略了新的数据库参数。为什么会发生这种情况,我该如何解决这个问题?因为,将现有数据从数据库复制到新数据库是我项目的常见需求,如果我无法从转储中恢复我的数据,那么只需要一次崩溃就可以永远丢失我的记录。所以请帮我解决这个问题。
此致
找到原因了。问题在于在传递 --nsFrom
和 --nsTo
参数的值时使用单引号。在这样做的同时,在某些环境中,mongo 继续将转储恢复到现有数据库而不是新数据库,从而在现有数据和正在恢复的数据之间造成冲突,从而产生“重复键错误”。当你遇到这种情况时,要么使用双引号来传递 --nsFrom
和 --nsTo
参数的值,要么根本不使用任何引号。
这显然是 MongoDB 服务器系统或其语法中的错误。 MongoDB开发团队必须注意这一点,并在下次更新中纠正它。