The documentation and diagnostic output around the use of the gzip feature are confusing, as shown by the original report below. We need to rethink command option interactions and what diagnostics we give. Once done, we need to update documentation to match.
mongodump --host localhost --port 27201 --db test --collection test --gzip
In a dump/test subfolder it created:
Now restore should work without pointing to the bson file, but since we are using --gzip the work around seems to be to point to test.bson.gz. Let’s try what did not work before first.
mongorestore --host localhost --port 27201 --db test --collection testRename --gzip
2018-04-25T16:27:47.341-0700 the --db and --collection args should only be used when restoring from a BSON file. Other uses are deprecated and will not exist in the future; use --nsInclude instead
2018-04-25T16:27:47.342-0700 using default 'dump' directory
2018-04-25T16:27:47.342-0700 checking for collection data in dump
2018-04-25T16:27:47.343-0700 Failed: error scanning filesystem: file dump is a directory, not a bson fil
It doesn’t like a couple of things. Perhaps the use of --db, but also the fact that dump is not a bson file. It would seem that pointing directly to the bson file would work: passing the path to the bson file at the end worked, including importing of indexes. Let’s try that first.
mongorestore --host localhost --port 27201 --db test --collection testRename --gzip dump/test/test.bson.gz
2018-04-25T16:31:52.462-0700 checking for collection data in dump/test/test.bson.gz
2018-04-25T16:31:52.466-0700 reading metadata for test.testRename from dump/test/test.metadata.json.gz
2018-04-25T16:31:52.501-0700 restoring test.testRename from dump/test/test.bson.gz
2018-04-25T16:31:52.568-0700 restoring indexes for collection test.testRename from metadata
2018-04-25T16:31:52.587-0700 finished restoring test.testRename (1 document)
This worked perfectly, but it is not the syntax I thought should be used.