We are trying to do a simple MongoDump on a relatively small DB.
our steps are simple:
export
drop exisiting DB from target machine
import on target machine
The MongoDump executes perfectly.
mongodump --out=/root/mongo-prod
The same goes for the DB drop:
mongo db_name --eval "db.dropDatabase()"
On the other hand, After calling mongoRestore
mongorestore --stopOnError --drop --db db_name /root/mongo-prod-{{ build }}/db_name/
The import process starts, and hangs on 3 specific collections with the following error repeating:
no collection options to restore
restoring db_name.Collection4 from file /root/mongo-prod-31/db_name/Collection4.bson
file /root/mongo-prod-31/db_name/Collection4.bson is 56625 bytes
using 1 insertion workers
[########################] db_name.Collection1 106.7 KB/106.7 KB (100.0%)
[########################] db_name.Collection2 63.5 KB/63.5 KB (100.0%)
[######..................] db_name.Collection3 6.7 MB/25.9 MB (25.8%)
[########################] db_name.Collection4 55.3 KB/55.3 KB (100.0%)
[########################] db_name.Collection1 106.7 KB/106.7 KB (100.0%)
[########################] db_name.Collection2 63.5 KB/63.5 KB (100.0%)
[######..................] db_name.Collection3 6.7 MB/25.9 MB (25.8%)
[########################] db_name.Collection4 55.3 KB/55.3 KB (100.0%)
******* This loops infinitely *******
p.s adding --repair to the mongodump command, creates a different error on mongorestore:
Failed: restore error: db_name.Collection1: error restoring from /root/mongo-prod-33/db_name/Collection1.bson: insertion error: E11000 duplicate key error index: db_name.Collection1.$_id_ dup key: { : ObjectId('5651802de4b0293285f7f508') }
I just spent an hour with this:
Read from archive
--archive=/backup...
Ignore the archive argument and wait for stdin
--archive /backup
Seems arguments work with either arg value or arg=value, just not archive...
Obviously, the problem was related to MongoDB write concerns. From the MongoDB documentation (version 3.2):
Write concern describes the level of acknowledgement requested from MongoDB for write operations to a standalone mongod or to replica sets or to sharded clusters.
In a replica set configuration, this option defines how many replicas write operation needs to be written to, before it is considered successful.
The mongorestore
utility has default write concern set to majority. Such value require acknowledgment that write operations have propagated to the majority of voting nodes including the primary. If you have >= 1/2 of your replica set (voting!) members step down, mongorestore will hang forever, waiting for acknowledgment by the majority of members. From the docs:
If you do not specify the wtimeout option and the level of write concern is unachievable, the write operation will block indefinitely.
If you still need to perform database restoring, just specify --writeConcern '{w:0}'
in you mongorestore
command. This will disable acknowledgment of the write operations for current mongo connection and you will be able to restore your database.
Here is a link to documentation: https://docs.mongodb.com/v3.2/reference/write-concern
P.S. The same is acceptable for the latest MongoDB version 3.4.
I was facing the same issue on replica set, I was trying to restore on Primary while secondary (in replica set) was down. I started secondary and then it started restoring successfully.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With