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.
Related
I am planning to upgrade the existing MongoDB replicaset in version 3.6 to version 4.4.
I was wondering if I can add the new members in the version 4.4 to the existing replicaset (equal to the original number of members) and remove the old members once they are successfully added.
Is this possible as I didn't find a good article saying that can be done?
No, MongoDB requires that you upgrade through each major version.
The nodes on 3.6 might not understand the replication language used by the nodes on 4.4 and vice versa.
MongoDB only ensures operability between adjacent versions, so 3.6 and 4.0 are sure work together in the same replica set.
You may get lucky and find that 3.6 and 4.4 are able to coexist peacefully.
However, if you decide to try that, be prepared to recover from all of the nodes on both versions crashing and becoming corrupted, just in case.
I'm trying to migrate a cluster from MongoDB 3.4 to 3.6.
When adding a new member which uses MongoDB 3.6, the initial synchronization fails with the following error:
Sync source had no feature compatibility version document at src/mongo/db/repl/replication_coordinator_impl.cpp 679
As I can see, this is a well-known error for those who try to migrate from 3.2 to 3.6. In my case, however, I'm trying to migrate from 3.4 (3.4.14 to be more specific, as reported by db.version() on every instance of the cluster) to 3.6. Since MongoDB official documentation makes no reference to the version 3.5, I'm not sure what am I supposed to do.
What am I doing wrong?
You can definitely upgrade a replica set or sharded cluster from MongoDB 3.4 to 3.6. Upgrades are currently only supported between adjacent major releases, so before upgrading to MongoDB 3.6 you need to complete the upgrade to MongoDB 3.4.
Sync source had no feature compatibility version document
This error message indicates that you've missed a prerequisite in prior upgrades: the replica set does not have featureCompatibilityVersion set to 3.4. This would be the case if you previously upgraded from a version of MongoDB older than 3.4 and haven't enabled backwards-incompatible features yet.
The Feature Compatibility Version (FCV) setting was added in MongoDB 3.4 to provide control over enabling backwards-incompatible data features that could complicate the downgrade process. For example, MongoDB 3.4 adds views, additional index formats (supporting collation and case-sensitive indexes), and a new Decimal BSON type.
After upgrading to 3.4 and confirming the likelihood of a downgrade is minimal, the FCV should be set using:
db.adminCommand( { setFeatureCompatibilityVersion: "3.4" } )
This is a prerequisite to upgrading to MongoDB 3.6 which has a similar final upgrade step to enable backwards-incompatible 3.6 features by setting the FCV to "3.6".
You can check the current FCV using:
db.adminCommand( { getParameter: 1, featureCompatibilityVersion: 1 } )
Since MongoDB official documentation makes no reference to the version 3.5, I'm not sure what am I supposed to do.
MongoDB 3.5 (and releases with the second component being an odd number) are not referred to in the upgrade notes as those are development releases (see: MongoDB version numbers). MongoDB 3.5 is the development release series leading up to the MongoDB 3.6 production release series.
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 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.
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).