[DOCS-7573] Clarify the behavior of mongorestore --archive with --db or --collection options Created: 04/Apr/16  Updated: 30/Oct/23  Resolved: 13/Jul/19

Status: Closed
Project: Documentation
Component/s: manual, Server, tools
Affects Version/s: None
Fix Version/s: Server_Docs_20231030

Type: Improvement Priority: Major - P3
Reporter: Kelsey Schubert Assignee: Kay Kim (Inactive)
Resolution: Done Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to DOCS-12579 mongorestore docs show deprecated exa... Closed
is related to SERVER-23488 mongorestore --db with --archive sele... Closed
Participants:
Days since reply: 4 years, 30 weeks, 4 days ago
Epic Link: DOCSP-1769

 Description   

https://docs.mongodb.org/manual/reference/program/mongorestore/#cmdoption--db

Specifies a database for mongorestore to restore data into. If the database does not exist, mongorestore creates the database. If you do not specify a <db>, mongorestore creates new databases that correspond to the databases where data originated and data may be overwritten. Use this option to restore data into a MongoDB instance that already has data.

--db does not control which BSON files mongorestore restores. You must use the mongorestore path option to limit that restored data.

However, as noted at https://docs.mongodb.org/manual/reference/program/mongorestore/#restore-a-database-from-an-archive-file

--db is used to select which database is restored from the archive.

If --db or --collection specifies a database or collection not contained in the dump archive no data will be restored:

mongodump --archive=test.archive --db test --collection foo
2016-04-04T16:44:44.555-0400	writing test.foo to archive 'test.archive'
2016-04-04T16:44:44.555-0400	done dumping test.foo (1 document)
 
mongorestore --archive=test.archive --db test --collection bar
2016-04-04T16:44:50.917-0400	setting number of parallel collections to number of parallel collections in archive (8)
2016-04-04T16:44:50.942-0400	creating intents for archive
2016-04-04T16:44:50.986-0400	done
 
mongorestore --archive=test.archive --db test --collection foo
2016-04-04T16:44:56.531-0400	setting number of parallel collections to number of parallel collections in archive (8)
2016-04-04T16:44:56.556-0400	creating intents for archive
2016-04-04T16:44:56.619-0400	reading metadata for test.foo from archive 'test.archive'
2016-04-04T16:44:56.619-0400	restoring test.foo from archive 'test.archive'
2016-04-04T16:44:56.626-0400	error: E11000 duplicate key error collection: test.foo index: _id_ dup key: { : ObjectId('5702d13cd25b3ef5b9fe55b3') }
2016-04-04T16:44:56.928-0400	restoring indexes for collection test.foo from metadata
2016-04-04T16:44:56.928-0400	finished restoring test.foo (1 document)
2016-04-04T16:44:56.928-0400	done

I think this distinction should be highlighted as part of the description of the --db option quoted above.



 Comments   
Comment by Githook User [ 13/Jul/19 ]

Author:

{'name': 'Kay Kim', 'email': 'kay.kim@10gen.com', 'username': 'kay-kim'}

Message: DOCS-7573,DOCS-12579: update output messages - different from 4.2
Branch: v3.4
https://github.com/mongodb/docs/commit/7d203dc30dbd0c3eca1b36c0f2c74dcc3fdada13

Comment by Githook User [ 13/Jul/19 ]

Author:

{'name': 'Kay Kim', 'email': 'kay.kim@10gen.com', 'username': 'kay-kim'}

Message: DOCS-7573,DOCS-12579: update mongorestore in prep for go changes
Branch: v3.4
https://github.com/mongodb/docs/commit/a58e342944ccb4e9f621a08766795dc150e6de12

Comment by Githook User [ 13/Jul/19 ]

Author:

{'name': 'Kay Kim', 'username': 'kay-kim', 'email': 'kay.kim@10gen.com'}

Message: DOCS-7573,DOCS-12579: update output messages - different from 4.2
Branch: v3.6
https://github.com/mongodb/docs/commit/40fd5f6c97a861e37a585a720d667ed22124d30c

Comment by Githook User [ 13/Jul/19 ]

Author:

{'name': 'Kay Kim', 'username': 'kay-kim', 'email': 'kay.kim@10gen.com'}

Message: DOCS-7573,DOCS-12579: update mongorestore in prep for go changes
Branch: v3.6
https://github.com/mongodb/docs/commit/c93d1431f85c927c1cb34d0163d7ca30c3c277d6

Comment by Githook User [ 13/Jul/19 ]

Author:

{'name': 'Kay Kim', 'username': 'kay-kim', 'email': 'kay.kim@10gen.com'}

Message: DOCS-7573,DOCS-12579: update output messages - different from 4.2
Branch: v4.0
https://github.com/mongodb/docs/commit/2bcb5d93d6577bc0da5c35232173198a19fb541a

Comment by Githook User [ 12/Jul/19 ]

Author:

{'name': 'Kay Kim', 'username': 'kay-kim', 'email': 'kay.kim@10gen.com'}

Message: DOCS-7573,DOCS-12579: update mongorestore in prep for go changes
Branch: v4.0
https://github.com/mongodb/docs/commit/86a076210a7c6ea07b5b194d7735712b412242cf

Comment by Githook User [ 12/Jul/19 ]

Author:

{'name': 'Kay Kim', 'username': 'kay-kim', 'email': 'kay.kim@10gen.com'}

Message: DOCS-7573,DOCS-12579: update mongorestore in prep for go changes
Branch: master
https://github.com/mongodb/docs/commit/0390bc4026820f752e42f07f42bad31c2f73624f

Comment by Bijith Kumar [ 29/Jun/16 ]

The verbose log also does not provide any error message or warning if you specify a new db name while restoring.

Spent half a day debugging why my restore doesn't work.

mongodump --host localhost --archive=myCollection.gz --gzip --db 'MyDB' --collection myCollection -vvvvvv
2016-06-29T14:18:15.492-0700 enqueued collection 'MyDB.myCollection'
2016-06-29T14:18:15.493-0700 dump phase I: metadata, indexes, users, roles, version
2016-06-29T14:18:15.493-0700 reading indexes for `MyDB.myCollection`
2016-06-29T14:18:15.495-0700 archive prelude MyDB.myCollection
2016-06-29T14:18:15.495-0700 dump phase II: regular collections
2016-06-29T14:18:15.495-0700 finalizing intent manager with legacy prioritizer
2016-06-29T14:18:15.495-0700 dumping up to 1 collections in parallel
2016-06-29T14:18:15.495-0700 starting dump routine with id=0
2016-06-29T14:18:15.495-0700 MuxIn open MyDB.myCollection
2016-06-29T14:18:15.496-0700 will listen for SIGTERM, SIGINT and SIGHUP
2016-06-29T14:18:15.497-0700 Mux open namespace MyDB.myCollection
2016-06-29T14:18:15.497-0700 writing MyDB.myCollection to archive 'myCollection.gz'
2016-06-29T14:18:15.498-0700 counted 3 documents in MyDB.myCollection
2016-06-29T14:18:15.498-0700 done dumping MyDB.myCollection (3 documents)
2016-06-29T14:18:15.498-0700 MuxIn close MyDB.myCollection
2016-06-29T14:18:15.498-0700 Mux close namespace MyDB.myCollection
2016-06-29T14:18:15.498-0700 ending dump routine with id=0, no more work to do
2016-06-29T14:18:15.498-0700 dump phase III: the oplog
2016-06-29T14:18:15.498-0700 done
2016-06-29T14:18:15.498-0700 Mux finish
2016-06-29T14:18:15.499-0700 mux completed successfully

mongorestore --gzip --archive=myCollection.gz --db MyDB_Restored -vvvvvvv
2016-06-29T14:33:04.993-0700 checking options
2016-06-29T14:33:04.998-0700 dumping with object check disabled
2016-06-29T14:33:05.013-0700 connected to node type: standalone
2016-06-29T14:33:05.014-0700 standalone server: setting write concern w to 1
2016-06-29T14:33:05.014-0700 using write concern: w='1', j=false, fsync=false, wtimeout=0
2016-06-29T14:33:05.074-0700 archive prelude MyDB.myCollection
2016-06-29T14:33:05.074-0700 archive format version "0.1"
2016-06-29T14:33:05.074-0700 archive server version "3.2.1"
2016-06-29T14:33:05.074-0700 archive tool version "3.2.1"
2016-06-29T14:33:05.091-0700 creating intents for archive
2016-06-29T14:33:05.092-0700 using as dump root directory
2016-06-29T14:33:05.093-0700 reading collections for database MyDB in MyDB
2016-06-29T14:33:05.094-0700 demux Open
2016-06-29T14:33:05.094-0700 found collection MyDB.myCollection metadata to restore
2016-06-29T14:33:05.214-0700 demux namespaceHeader:

{MyDB myCollection false 0}

2016-06-29T14:33:05.214-0700 demux namespaceHeader:

{MyDB myCollection true -6057897897989027830}

2016-06-29T14:33:05.215-0700 demux checksum for namespace MyDB.myCollection is correct (-6057897897989027830), 87 bytes
2016-06-29T14:33:05.215-0700 demux End
2016-06-29T14:33:05.215-0700 demux finishing (err:<nil>)
2016-06-29T14:33:05.215-0700 restoring up to 4 collections in parallel
2016-06-29T14:33:05.215-0700 starting restore routine with id=3
2016-06-29T14:33:05.215-0700 ending restore routine with id=3, no more work to do
2016-06-29T14:33:05.215-0700 starting restore routine with id=1
2016-06-29T14:33:05.215-0700 ending restore routine with id=1, no more work to do
2016-06-29T14:33:05.215-0700 starting restore routine with id=0
2016-06-29T14:33:05.215-0700 ending restore routine with id=0, no more work to do
2016-06-29T14:33:05.215-0700 will listen for SIGTERM and SIGINT
2016-06-29T14:33:05.215-0700 starting restore routine with id=2
2016-06-29T14:33:05.215-0700 ending restore routine with id=2, no more work to do
2016-06-29T14:33:05.215-0700 done

Generated at Thu Feb 08 07:54:33 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.