I trying to migrate an old application, using MongoDB 2.4 to a host, running MongoDB 3.0 in Docker container. For test purpose I am copying the data via ssh tunnel from the older to the newer version.
As I read about the updating process of MongoDB, first I should use Mongo 2.6 and then 3.0. However my test with avoiding the step with version 2.6 was successful and the database works fine. Could somebody explain me is that really possible or I have misunderstood something? It's really strange for me.
Upgrading from 2.4 to 2.6, prior to upgrading to 3.0 is a requirement according to the documentation:
To upgrade an existing MongoDB deployment to 3.0, you must be running
2.6. If you’re running a version of MongoDB before 2.6, you must upgrade to 2.6 before upgrading to 3.0. See Upgrade to 2.6 for the
procedure to upgrade from 2.4 to 2.6. Once upgraded to MongoDB 2.6,
you cannot downgrade to any version earlier than MongoDB 2.4.
Having said that, if you have run the corresponding test cases for your application, with a good test coverage, the indexes are working properly, and nothing has been broken I can not see a reason to worry about but ideally they suggest to migrate to 2.6 and then make the move to 3.0 to avoid data corruption.
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.
I want to upgrade all members to 3.4, however, I want to be able to switch back to 2.6.8 if anything goes wrong. In order to do this, I was hoping to add a new member 3.0 or 3.4 member to the existing replica set (on 2.6.8), replicate the data, then break it out and create a separate replica set on 3.4. After breaking out the synced up 3.x member, I would add further 3.x members to it and switch my app to use the new replica set. If the app breaks, I am planning to switch back to the older replica set. I read that replica set members can be on different versions. I am having trouble locating information on specific versions and potential issues. Also, the reason I keep mentioning 3.0 as well as 3.4, is because when I started planning, the latest version was 3.0, I also heard that I have to upgrade members incrementally, so from 3.0 to 3.2 to 3.4. Any advice?
This seems to be documented in Mongo Release Notes for 3.0, 3.2 and 3.4.
https://docs.mongodb.com/manual/release-notes/3.4-upgrade-replica-set/
"upgrade an existing MongoDB deployment to 3.4, you must be running a 3.2-series release.
To upgrade from a version earlier than the 3.2-series, you must successively >upgrade major releases until you have upgraded to 3.2-series. For example, if >you are running a 3.0-series, you must upgrade first to 3.2 before you can >upgrade to 3.4."
https://docs.mongodb.com/manual/release-notes/3.2-upgrade/
https://docs.mongodb.com/manual/release-notes/3.2-downgrade/
"To upgrade an existing MongoDB deployment to 3.2, you must be running a 3.0->series release.
To upgrade from a 2.6-series release, you must upgrade to the latest 3.0-series >release before upgrading to 3.2. For the procedure to upgrade from the 2.6->series to a 3.0-series release, see Upgrade to 3.0."
https://docs.mongodb.com/manual/release-notes/3.0-upgrade/
"To upgrade an existing MongoDB deployment to 3.0, you must be running 2.6. If >you’re running a version of MongoDB before 2.6, you must upgrade to 2.6 before >upgrading to 3.0. See Upgrade to 2.6 for the procedure to upgrade from 2.4 to >2.6. Once upgraded to MongoDB 2.6, you cannot downgrade to any version earlier >than MongoDB 2.4."
In a previous project, we had to upgrade from 2.6.8 -> 3.0 (upgrade members in a rolling manner to keep the cluster up and running). Our rollback plan was to decide at this point whether everything was OK and if not rollback to 2.6.8. If it was ok, upgrade from 3.0 -> 3.2 (again, a rolling upgrade). We did not try a two step downgrade, but I guess it is theoretically possible based on what Mongo documents. From 3.4, you will have to review the release notes to see if it is theoretically possible!
Also note that you need to consider upgrading your client drivers along the way. There are compatibility issues with client driver versions as well.
It is possible to update mongodb (Currently in version 2.0.6 and I need > 2.2) and keep databases ?
Mongodb running on Debian 7
MongoDB 2.0 data files are compatible with 2.2-series binaries without
any special migration process. However, always perform the upgrade
process for replica sets and sharded clusters using the procedures
that follow.
As said on the mongodb release notes. Also when your making an upgrade, since your current version is 2.0.6 you need to upgrade to 2.2 first.
If you want to go up to the latest version you have to keep upgrading version one by one as said on the release notes here.
Upgrading a Standalone version
Download binaries of the latest release in the 2.2 series from the MongoDB Download Page.
Shutdown your mongod instance. Replace the existing binary with the 2.2 mongod binary and restart MongoDB.
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 a production mongoDB 2.0 server running on a single machine. I need to upgrade it to the latest version. Would it be possible to just restore the dump from old server into the new server? Or would I have to do it one upgrade at a time?
No, in the general case, absolutely not. Best practice is to upgrade through each major version, following the upgrade instructions in each set of release notes. You can do this without downtime if you are running a replica set, at least from 2.4 -> 3.0 (I'm not as familiar with 2.0 and 2.2 since they are ancient).