I would like to know whether it is possible to upload MongoDB from 2.2 to 3.2 without any intermediary upgrades. If it is possible please share a resource that can follow. I would like to know what things to looks out for when up grading
No you can't.
From the documentation,
Upgrade Requirements
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 MongoDB to 3.0.
Related
I need to update MongoDB from version 2.6 to 4.2.6.
Could you please suggest effective way to upgrade the version without losing data or any kind of trouble.
Thank you in advance.
Each version has its associated release notes.
Upgrades must be done one version at a time (2.6 -> 3.0 -> 3.2 etc.).
Read the 3.0 release notes, identify which of them apply to your application, follow them, install 3.0 binaries, test your application, bump FCV if applicable (does not apply to 3.0 but will apply to later versions), test your application again, repeat the process for 3.2, etc.
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.
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.
Why is 3.0.* ok but 3.2 version has to specifically be 3.2.6? Is 3.2.1 ok?
Any version is fine when doing a fresh install with parse-server but from parse.com you will not be able to move to 3.2. Seems that migration tool wont allow it.
I moved to 3.0 and from there did backup/restore to 3.2.
However i would always strongly suggest that one in general runs the latest version if you can.
I do know that all test on mongodb 3.2.6 are passing including geo queries.
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).