mongorestore hangs indefinitely

Question

I'm trying to restore a database using mongorestore from a gzip file. The database is ~89MB in size, with the gzip file being about 4.4MB.

However, the restore hangs indefinitely without and error message. How should I troubleshoot this?

The command I run is:

mongorestore --gzip --archive ./my-db.gz --drop -u admin --authenticationDatabase admin --verbose=5

And the response is thus:

2018-01-09T15:47:45.089+0100    standard input is a terminal; reading password from terminal
Enter password:

2018-01-09T15:47:46.508+0100    will listen for SIGTERM, SIGINT, and SIGKILL
2018-01-09T15:47:46.509+0100    checking options
2018-01-09T15:47:46.509+0100        dumping with object check disabled
2018-01-09T15:47:46.527+0100    connected to node type: standalone
2018-01-09T15:47:46.528+0100    standalone server: setting write concern w to 1
2018-01-09T15:47:46.528+0100    using write concern: w='1', j=false, fsync=false, wtimeout=0

Here, it stops forever. The database is successfully created, but remains 0b in size.

Curiously, the database overview in MongoDB Compass shows the single collection in the database having ~28k documents, which is what I expect, with average size and other metadata apparently correct, but nothing can be read for it.

I've exported the db from a live cluster and am trying to import into my local dev environment, running a single instance through Docker.

Where should I go from here?

Thanks.

Answer 1

I found the solution.

If I run the command with --archive ./my-db.gz, I get the deadlock. If I do --archive=./my-db.gz, it restores properly (i.e. the equals sign is required).

I'm running MacOSX High Sierra (10.13.2) with MongoDB installed from brew; version:

mongorestore version: r3.4.1
git version: 4a0fbf5245669b55915adf7547ac592223681fe1
Go version: go1.7.5
   os: darwin
   arch: amd64
   compiler: gc
OpenSSL version: OpenSSL 1.0.2k  26 Jan 2017

Answer 2

for me the damn thing got stuck at a percentage for around 5 mins then increased on its own. Not sure why :/ network activity was good, disk is also good. not sure how to debug this further.

Answer 3

seems like this is the correct behavior, although it's strange

qouting from docs

  To restore from the standard input, run mongorestore with the --archive option but omit the filename.

so the program was waiting for archive to be piped to standard input

so it can work like this

mongorestore --gzip --archive=./my-db.gz --drop -u admin --authenticationDatabase admin --verbose=5

or

mongorestore --gzip --archive --drop -u admin --authenticationDatabase admin --verbose=5 < my-db.gz