Mongorestore无法将现有数据库复制/克隆到新的数据库
我在Windows 10 Pro上运行的PC中的默认位置中安装了MongoDB版本5.0.7。我有一个名为MyDB的数据库,其中包含一个称为产品的集合。我想将MyDB数据库复制到一个名为NewDB的新数据库中。为此,我正在尝试使用mongodump
和mongorestore
命令,如上所述 thou> terree ye >>>>>>。在这样做的同时,尽管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。由于MyDB已经包含具有具有独特ID的文档的产品集合,因此它创建了一场冲突,生成了重复的密钥错误。
作为替代方案,在执行mongorestore
时,我将新数据库的名称放在两个中 - nsfrom
and -nsto
参数有所不同:
mongorestore --archive="mongodump-mydb" --nsFrom='newdb.*' --nsTo='newdb.*'
然而,它会产生相同的错误。
不知何故,Mongo似乎完全忽略了新的数据库参数。为什么会发生这种情况?如何解决这个问题?因为,将现有数据从数据库中复制到新数据是我项目的共同要求,如果我不能从转储中恢复我的数据,那么它只会使我的记录永远丢失。因此,请帮助我解决这个问题。
问候
I have MongoDB version 5.0.7 installed in the default location in my PC running on Windows 10 Pro. I have a database named mydb which contains a collection called products. I want to copy the mydb database into a new database called newdb. For that, I’m trying to use mongodump
and mongorestore
commands as mentioned here. While doing so, although mongodump
is executing and creating the dump file properly, the mongorestore
command fails everytime generating a duplicate key error.
The command I use to dump the mydb database to an archive:
mongodump --archive="mongodump-mydb" --db=mydb
The command I use to restore the database from the dump to a new database:
mongorestore --archive="mongodump-mydb" --nsFrom='mydb.*' --nsTo='newdb.*'
The error message that I get:
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.
Surprisingly, it seems to restore the collection products in mydb database instead of newdb. As mydb already contains the products collection having rows of documents with unique ids, it’s creating a clash generating the duplicate key error.
As an alternative, while executing mongorestore
I put the name of the new database in both --nsFrom
and --nsTo
arguments to check if it makes some difference:
mongorestore --archive="mongodump-mydb" --nsFrom='newdb.*' --nsTo='newdb.*'
Yet, it generates the same error.
Somehow, mongo seems to be ignoring the new database argument altogether. Why is this happening and how do I solve this problem? Because, copying existing data from a database into a new one is a common requirement of my project, and if I can’t restore my data from dump, all it takes is a crash to loose my records forever. So please help me in resolving this issue.
Regards
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
我找到了原因。问题在于使用
的值-NSFROM
和-nsto
参数时使用单引号。在这样做的同时,在某些环境中,Mongo继续将转储恢复到现有数据库而不是新数据库,从而在现有数据和正在恢复的数据之间产生冲突,从而生成“重复键错误”。当您遇到这种情况时,要么使用双引号传递的值-NSFROM
和-nsto
参数,或者根本不使用任何引用。这绝对是MongoDB服务器系统或其语法中的错误。 MongoDB开发团队必须注意这一点,并在下一个更新中对其进行纠正。
I found the reason. The problem lies in using single quotes while passing the values of
--nsFrom
and--nsTo
arguments. While doing so, in some environments, mongo keeps on restoring the dump to the existing database instead of the new one, thus creating a clash between the existing data and the data being restored generating the “duplicate key error”. When you encounter such a scenario, either use double quotes to pass the values of--nsFrom
and--nsTo
arguments or don’t use any quote at all.This definitely seems to be a bug in MongoDB Server system or its syntax. MongoDB development team must take note of this and rectify it in the next update.