Mongodb Upgrade from 2.6 to 3.2 and 3.4

Note: To upgrade the mongodb version from 2.6 to 3.2/3.4 version first you need to upgrade to mongodb 3.0 version then need to upgrade to  3.2 then 3.4 version.

Upgrade Recommendations and Checklists

When upgrading, consider the following:

Preparedness:

Before upgrading MongoDB, always test your application in a staging environment before deploying the upgrade to your production environment.

Backup 

Before going to upgrade the mongodb version it is recommended to backup of the complete data . If any issues found in upgrade method we can restore from the backup.

Upgrade Requirements

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.

If your existing MongoDB deployment is already running with authentication and authorization, your user data model authSchema must be at least version 3. To verify the version of your existing authSchema.

To upgrade your authSchema version follow the below method 

Replica Sets

For a replica set, it is only necessary to run the upgrade process on the primary as the changes will automatically replicate to the secondaries.

Requirements

To upgrade the authorization model, you must have a user in the admin database with the role userAdminAnyDatabase.

Procedure

1)Connect to MongoDB instance.

Connect and authenticate to the mongod instance for a single deployment  or primary server of replica set  as an admin database user with the role userAdminAnyDatabase.

2) Upgrade authorization schema.

Use the authSchemaUpgrade command in the admin database to update the user data using the mongo shell.

Run authSchemaUpgrade command.

db.getSiblingDB("admin").runCommand({authSchemaUpgrade: 1 });

Downgrade Limitations

Once upgraded to MongoDB 3.0, you cannot downgrade to a version lower than 2.6.8.

If you upgrade to 3.0 and have run authSchemaUpgrade, you cannot downgrade to 2.6 without disabling --auth or restoring a pre-upgrade backup, as authSchemaUpgrade discards theMONGODB-CR credentials used in 2.6. 

Upgrade a Replica Set to 3.0

Prerequisites

• If the oplog contains entries generated by versions of MongoDB that precede version 2.2.1, you must wait for the entries to be overwritten by later versions before you can upgrade to MongoDB 3.0.
• Stricter validation in MongoDB 3.0 of replica set configuration may invalidate previously-valid replica set configuration, preventing replica sets from starting in MongoDB 3.0. For more information, 
• All replica set members must be running version 2.6 before you can upgrade them to version 3.0. To upgrade a replica set from an earlier MongoDB version, upgrade all members of the replica set to version 2.6 first, and then follow the procedure to upgrade from MongoDB 2.6 to 3.0.

Upgrade Binaries

You can upgrade from MongoDB 2.6 to 3.0 using a “rolling” upgrade to minimize downtime by upgrading the members individually while the other members are available:

1)Upgrade secondary members of the replica set.

Upgrade the secondary members of the set one at a time by shutting down the mongod and replacing the 2.6 binary with the 3.0 binary.

 MMAP() storage engine:

For MMAP() storage engine : After upgrading a mongod instance, wait for the member to recover to SECONDARY state before upgrading the next instance. To check the member’s state, issue rs.status() in the mongo shell

Wired tiger  storage engine: (Change Replica Set Storage Engine to WiredTiger)

Need to change the storage engine in the config file and start mongod with new dp path  then  resync from primary server  , repeat the same method for all replica members 

2)Step down the replica set primary.

Use rs.stepDown() in the mongo shell to step down the primary and force the set to failover.rs.stepDown() expedites the failover procedure and is preferable to shutting down the primary directly.

3) Upgrade the primary.

When rs.status() shows that the primary has stepped down and another member has assumed PRIMARY state, shut down the previous primary and replace the mongod binary with the 3.0 binary and start the new instance.

Replica set failover is not instant and will render the set unavailable to accept writes until the failover process completes. This may take 30 seconds or more: schedule the upgrade procedure during a scheduled maintenance window.

RollBack plan:

If any issues during the upgrade process we will restore the data from the backup .