You certainly have a difference of version between mongodump vs your mongoDB server ( 3.6 vs 4.0).
You can use docker to the rescue :
docker run --rm -v $(pwd):/workdir/ -w /workdir/ mongo:4.0 mongodump -h server -d $database --out /workdir/dump/
With docker you can use a precise version of tools cli without install it.
You can even specify an alias (...
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
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. ...
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 ...
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 ...
You don't have the required privileges for the config database.
See https://docs.mongodb.com/manual/reference/built-in-roles/ :
Provides the same privileges as readWrite on all databases except local and config.
Provides the same access to user administration operations as userAdmin on all ...
As at MongoDB 4.0, collection metadata doesn't include a last modified timestamp and there is no record of when mongodump last ran (or what collections were dumped).
You could write a custom script if you have a means of identifying relevant changes in your deployment since your last backup timestamp, but there are some potentially tricky aspects such as ...
A quote from the horse's mouth (ie. https://docs.mongodb.com/manual/core/backups/#back-up-with-mongodump):
mongodump and mongorestore are simple and efficient tools for backing up
and restoring small MongoDB deployments, but are not ideal
for capturing backups of larger systems.
As per MongoDB BOL Here
mongodump is a utility for creating a binary export of the contents of a database. mongodump can export data from either mongod or mongos instances.
mongodump only captures the documents in the database.The resulting backup is space efficient.
By default, mongodump does not capture the contents of the local database.
Changed in ...
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 ...
MongoDB will eventually use all free memory, always! Of course in the situation where data and it indexes are smaller than free memory, mongod cannot fill whole memory.
Now, when you do backups, mongod reads all needed data (for those backups) to the memory and let it (the data) be there as long as it has free space. When there is no free memory anymore and ...
Yes, when you are connecting to replica set, you must give RS name at start of connection string. You are (here) connecting to replica set, not cluster (even your RS is named "Cluster0-shard-0). BUT, if you are really taking backup of cluster, you should use file system snapshots or if you want to use mongodump (the hard way), follow these instructions to ...
Upgrading to MongoDB 3.4 was necessary, since the cluster string did not appear to work with 3.2.
Also, based on the blog post for 'importing data', a small tweak to the host parameter seemed necessary, in the form of adding the 'Cluster0-shard-0/' prefix :
mongodump --host "Cluster0-shard-0/cluster0-shard-00-00-2djno.mongodb.net:27017,cluster0-shard-00-01-...
I found a an old doc (v3.0) Backup a Small Sharded Cluster with mongodump. This documentation doesn't exists anymore in new MongoDB versions.
This procedure is only for backing up the data from a small sharded cluster and does not cover recreating the sharded environment or capturing a point-in-time backup. As you've noticed, there is no mention of backing ...
It is not a small sharded cluster.
Mongodump will take around 5 hrs for 600GB and restore would take more than 5 hrs based on the indexes in place on your collection.
My best suggestion is:
If you have a backup already in place taken by Mongo Ops-Manager, use that and restore on the new environment.
If time is not really an issue in your case, use the ...
Why do two sets of heavy lifting ??? Let MongoDB do it.
For this example, suppose IP of SECONDARY is 10.30.50.70 with hostname myslave
STEP 01 : Enable Replica Set on the PRIMARY only
Make the following changes in /etc/mongodb.conf on the PRIMARY
enable authorization in /etc/mongodb.conf
authorization: enabled under the security YAML tag (MongoDB 2.6+)...