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.
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.
On starting meteor 1.4.1, I get this message:
Your development database is using mmapv1, the old, pre-MongoDB 3.0 database
engine. You should consider upgrading to Wired Tiger, the new engine. The
easiest way to do so in development is to run meteor reset. If you'd like to
migrate your database, please consult
https://docs.mongodb.org/v3.0/release-notes/3.0-upgrade/
I though Meteor looks after the mongodb side of things under the hood and I would need to fix it if it is not broken, Will it be a problem if left as is or should be better to upgrade, and how to go about it? Thanks
You can check it in here.
https://guide.meteor.com/1.4-migration.html#update-to-mongo-3_2
MDG recommended you to update. minimum version supported by metetor1.4 is Mongodb Version 2.6.
I have Meteor 1.2.2 installed and, according to MeteorBlog, it should comes Mongodb v3.0 or higher installed.
However, if a go on Mongo shell (meteor mongo) and do:
$ db.version()
I get: 2.6.7
Shouldn't it be 3.0? I tried meteor update and it says all packages are up to date.
Is there a way to update Mongodb to the latest version as accepted by Meteor?
Meteor 1.1 came with MongoDB support up to version 3 and you're supposed to be able to use Meteor in production along a MongoDB 3.0 database without major problems.
However they decided to keep the 2.6 branch regarding the Mongo version shipped with the Meteor tool and wait until Mongo 3.0 is mature enough before including it along official Meteor releases.
It means that Meteor updates its internal tool MongoDB version automatically, but at their own pace.
The local Mongo environment shipped with the Meteor development tool is something different than the actual Mongo deployment you usually use in production, and it is not required that the 2 versions be the same.
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.
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.