I have successfully upgraded a database from 2.4 to 4.0 using the following 3 step method:
use 2.4 mongobackup on the 2.4 database
delete all .json files from the outputted dump directory
use 4.0 mongorestore on the remaining .bson files
For the people who will come here in the future the issue was, I was using MongoDB 4.0 on the local and server was on 4.2:
Starting in version 4.2, mongodump uses Extended JSON v2.0 (Canonical) format for the metadata files. To parse these files for restore, use mongorestore version 4.2+ that supports Extended JSON v2.0 (Canonical or Relaxed mode) format.
As you said you are trying to import a MongoDB database, And you are using the MongoDB command such as mongorestore. And also as you said you have taken mongodump backup of MongoDB database , which MongoDB version is 2.4 & you are going to import that mongodump backup in MongoDB , which version is 3.6.
As I would like to say here as per MongoDB BOL ...
mongorestore -d demo -c dcoll C:\data\dump\twitter\tweets.bson
As i have gone through your MongoDB syntax query it seems to be correct.
As per your script code demo is database and dcoll is collection and you want to restore the (.bson) file of tweets.bson in your dcoll collection.
I would like to say that here before restore the (.bson) file in MongoDB. ...
Can anyone share their restore experiences that restored both indexes and mongodb_id?
As per MongoDB documentation here By default, mongorestore looks for a database backup in the dump/ directory.
New in version 3.6:
All MongoDB collections have UUIDs by default. When MongoDB restores collections, the restored collections retain their original UUIDs. When ...
Problem is in metadata.json files. You need to remove 'options' and it will work just fine. I even created small python tool to do this:
from glob import glob
for filename in sorted(glob('dump/*/*.metadata.json')):
with open(filename, 'r') as f:
data = json.loads(f.read())
if 'options' in data:
Find below the wordings from MongoDB official documentation
mongorestore can create a new database or add data to an existing database. However, mongorestore performs inserts only and does not perform updates. That is, if restoring documents to an existing database and collection and existing documents have the same value _id field as the to-...
Based on the oplog file you uploaded, the minimum timestamp is 1552888560 and maximum timestamp is 1553063754. But the --oplogLimit=1552828432 you mentioned in your question is not within the limit, which is less than the minimum timestamp value. That is the reason none of the documents were restored.
Run the following command from the folder where ...
As per MongoDB jira blog here mongorestore --oplog will not apply oplog entries captured during the mongodump operation, and exit with an error when attempting to use mongorestore with the restore role and a MongoDB deployment that uses access control. For additional information, please review the documentation on the restore role.
As it's a affects the ...
MongoDB 3.4 and newer servers can negotiate network compression if MongoDB clients/drivers have also been updated to support the compressed message format. Network compression was introduced as an optional feature in MongoDB 3.4 and is enabled by default for MongoDB 3.6+ servers.
Unfortunately the mgo driver used by mongodump (as at MongoDB 4.0) does not ...
With a 32-bit O/S the total addressable file size for MongoDB's MMAP storage engine is limited to ~2GB of data including indexes (and journal, if enabled). Given the 32-bit limitations for memory-mapped files, journaling is off by default on 32-bit MongoDB builds as otherwise the data limit would be halved. This is not a recommended configuration for any ...