can I use mongodump to get the data dump from mongo version2.0 and do mongorestore on mongo version 2.4. OR the best way is to use mongoimport/mongoexport and use json as the data format?
MongoDB's data model should be compatible between these releases, so dump will be able to work properly from 2.0 -> 2.4. (though going backward form 2.4 -> 2.0 is not supported: http://docs.mongodb.org/manual/release-notes/2.2/#mongodump-2-2-output-incompatible-with-pre-2-2-mongorestore)
Note: if all you are doing is upgrading your MongoDB installation on the same machine, there is no migration process you need to go through, i.e. no importing or exporting anything. You can just upgrade your mongo executables and everything should still work. (obviously you should still do a dump backup before doing this, but only as a safety precaution)
Related
Apologies if this question is too open-ended.
I have inherited an aging tech stack and am required to upgrade our 200GB MongoDB Community Edition v3.4 installation (hosted on Ubuntu 20) to MongoDB v5 in order to support some new features.
MongoDB advises that to install v5.0, one must be already on MongoDB v4.4:
https://www.mongodb.com/docs/manual/release-notes/5.0-upgrade-standalone/
They say that if you are on a version older than 4.4, then you need to incrementally upgrade to v4.4 before upgrading to v5.
However, if you follow the links in that official upgrade tutorial, you will find that in order to upgrade to any version of MongoDB, they insist on you upgrading version-by-version, successively.
So for me on v3.4 the upgrade path will look like this:
v3.4 -> v3.6 -> v4.0 -> v4.2 -> v4.4 -> v5.0.13
Following these tutorials:
https://www.mongodb.com/docs/manual/release-notes/3.6-upgrade-standalone/
https://www.mongodb.com/docs/manual/release-notes/4.0-upgrade-standalone/
https://www.mongodb.com/docs/manual/release-notes/4.2-upgrade-standalone/
https://www.mongodb.com/docs/manual/release-notes/4.4-upgrade-standalone/
https://www.mongodb.com/docs/manual/release-notes/5.0-upgrade-standalone/
I'm not entirely sure why this is necessary, as the tutorials themselves seem to mostly involve copying over newer binaries and then setting a feature compatibility version in the database config.
To test whether this was necessary I did a mongodump of our entire v3.4 database and then installed a standalone MongoDB v5.0.13 on the same server and then mongorestore to the new v5.0.13 database. Everything seems to work fine, mongorestore spent two hours recreating all the indexes as its last step (something various articles told me would not happen using the mongodump/mongorestore method).
I am able to connect Mongo clients to this new v5.0.13 Community instance without issue. All the data is there and I am able to query it just fine.
So my question is, why does MongoDB strongly advise doing the upgrade incrementally, one version at a time when dumping the database and restoring it to a new version of MongoDB seems to work just fine?
The only issues I have currently is having to rewrite some client code which is using an older Mongo Java driver. This is something I am going to have to do regardless of the upgrade method I used.
Our MongoDB instance is Community Edition and is a single, standalone instance (not a replica set) so I don't know if this matters. Perhaps the upgrade process described by MongoDB is for Mongo Cloud or for Enterprise?
I'm just looking for clarification on whether the simpler method I tried is going to cause me issues. Maybe I've missed something I hadn't considered.
After reading this in the official Mongo Documentation: https://docs.mongodb.com/database-tools/mongorestore/#restore-to-matching-server-version
I‘m having doubts on how the best practice is in the following case.
Our old Server has Mongo 4 installed and our new Server is Running Mongo 5. Both Stand-alone installations.
I can‘t install or Update Mongo on the old Server.
Is there a way on how i can transfer my databases without having Datacorruption or Problems like the official Documentation talks about?
I know i have to use the —gzip tag, but that‘s about it.
Thanks for helping.
It is a recommendation to use the same verdion
Mongo tools are now separate package and had its own version.
restore is compatible with mongo 4 and 5.
dump also compatible with verdion 4 and 5.
But if there are some unsupported things in mongo 5 from mongo 4 which is used in your schema and queries, you would take a dump and give a try out in your prestaging environment.
And do not forget to read about the release notes.
Apart from the mentioned versions, it also says
While mongodump may work on earlier versions of MongoDB server, any such compatibility is not guaranteed.
I have work a lot with MongoDB 2.6, then I decide to start using MongoDB 3.0.2.
1) When I create an Database using the shell command, the command return true but
the database is not created.
use NewDatabaseName
2) When i try to create some collections, sometime is created and sometime no
I'm using Debian 64Bit, latest version.
Anybody is having this issue?
MongoDB 3.0 is not compatible with all GUI.
For example today MongoVUE do not work at all.
But MongoDB Management Studio sounds like the only one that really work.
Also here some other post related.
mongodb version 3.0.0 client robomongo mongovue
Yes your problem is GUI-related. You can check out different tools on this page:
http://mongodb-tools.com/
I will most probably be using MongoChef from now on.
I have a production server that happens to be using a single instance of an older 32-bit version of MongoDB (2.0.0). I wanted to check a couple things before I got down and dirty with moving this data over to a separate server.
Will there be any conflicts doing a mongodump on a 32-bit install and a mongorestore to a 64-bit installation?
Is there any problems moving a 2.0 database dump to a 2.2.x installation?
I've read you are unable to do a mongodump of a 2.2 and correctly mongorestore to a 2.0, but I'm just doing a version upgrade. I've also read you can do replica sets between 32-bit and 64-bit versions of MongoDB, so I'm hoping this transition will work fine.
Just wanted to check, thanks!
Will there be any conflicts doing a mongodump on a 32-bit install and
a mongorestore to a 64-bit installation?
No, this will be fine, no problems - the BSON format will not be changed because of architecture
Is there any problems moving a 2.0 database dump to a 2.2.x
installation?
No problems here either, in fact you can just copy the data files directly if you wish (as long as the source DB is shut down at the time). That will in fact be faster because you won't have to rebuild indexes.
Recently, I have updated from MongoDB 1.6 to MongoDB 2.0.
I have populated several collections on MongoDB 1.6. After I upgrade to MongoDB 2.0, then start mongodb with the same --dbpath parameter, I found that all previous store collections are still there.
It seems that I don't have to manually backup and reload data into the newer version.
Question> When should we backup & reload data if we decide to upgrade to new version mongodb?
Thank you
You should always backup your data before changing versions - doesn't matter up or down. I'd recommend using mongodump which is super fast (I can tell from my experience, we were able to dump about 15M documents, 12GB database in 2 minutes). Once you've done this, upgrade the binaries and see if the existing data works. If not, restore from the dump using mongorestore.
It#s clearly documented that the database format did not change. So swapping the binaries should be good enough.