Tips For Upgrading to the Latest MongoDB Version

The latest versions of MongoDB are built to integrate new or improved features from the predecessor versions. For this reason, it is recommended to run the latest version for maximum performance and additional features. Besides, the latest versions may be as a result of fixed bugs depending on the MongoDB versioning.

MongoDB Versioning

MongoDB versions are of the form X.Y.Z. 

• When Y is even, i.e 4.0 or 4.2, this refers to a release series which is stable hence recommended for production. In this case new features are integrated which may result in backwards incompatibility.
• If Y is odd, i.e 4.1 or 4.3, this refers to development series which is not stable hence recommended for testing only.
• Z refers to a revision/patch number. Involves bug fixing and backward compatible changes.

Also considering the MongoDB driver versions is important towards ensuring a well performing database.

Considerations Before Upgrading

1. Backup: Midway the upgrade some crash may happen and in the end compromise the integrity of data the database was holding. Therefore, it is recommended to always make a backup of the data before upgrading to a certain version.
2. Maintenance Window: There may be some complexity that may arise when upgrading to some version if replica sets are involved. One needs to schedule enough time for this process so that you don’t encounter a high downtime.
3. Version Compatibility: Ensure to go through the release notes and check if your system setup will be compatible with the version you want to upgrade to. Also check the drivers compatibility documentation at  Driver Compatibility page if they can go in hand with the MongoDB version you want to upgrade to. For instance from MongoDB 4.2 upwards there is no support for Ubuntu 16.04 PPCLE system.
4. Change Streams: Change streams are designed for applications to access real-time data changes without necessarily tailing the oplog. For MongoDB versions before 4.0.7, change stream uses a version 0 v0 resume token whereas this version and the successors use a version 1 v1 resume tokens. It is recommended for clients to wait for the upgrade to complete before  resuming change streams when upgrading to version 4.0.7. 
5. Staging Environment Check: Ensure that all configurations are well set up before upgrading the production environment and they will be compatible with the new version you want to upgrade to. 
6.  Primary–Secondary–Arbiter (PSA) Architecture: MongoDB version 3.6 and above enable support for “majority” read concern by default. However, this configuration may result in storage cache pressure and the only way to prevent this is by disabling this parameter. Nevertheless, disabling this parameter may raise more concerns i.e:
   1. Support for transactions on sharded cluster will be affected in that: 
      1. if a shard has read concern “majority” disabled, it will throw an error for a transaction that writes to multiple shards.
      2. Read concern “snapshot” cannot be used for a transaction involving a shard with read concern “majority” disabled
   2. collMod commands that are responsible for modifying an index from  rolling back will not work. This dictates that if an operation needs to roll back, one must use the primary node to resync the affected nodes.
   3. Support for Change Streams for MongoDB 4.0 and earlier versions will also be disabled.
   4. Replica set transactions are not affected with the disabling of this parameter.

Procedures for Upgrading

1. Make a backup of your data.
2. Upgrade the mongod/mongos binary separately using the system package management tool alongside the official MongoDB packages. You can also upgrade the mongos by replacing the existing binaries with new binaries using these procedure:
   1. Download MongoDB binaries for the revision you want to upgrade to and store the downloaded compressed file in a temporary location.
   2. Shut down the instance.
   3. Use the downloaded binaries to replace the existing MongoDB binaries.
   4. Restart the instance.
3. If upgrading a replica set, upgrade each member separately by starting with the secondaries and the primary last. To upgrade the secondaries:
   1. Upgrade the mongod binary
   2. Wait for the secondary to recover into the SECONDARY state and after it finishes, upgrade the next instance. rs.status() is used to check for the member’s state in a mongo shell. RECOVERING and STARTUP states may show up but you will need to wait until it recovers to SECONDARY.
4. When upgrading the primary:
   1. In a mongo shell use rs.stepDown()to step down the primary as a way of initiating a normal failover. Since no writes will be accepted during the period, it is advisable to do the upgrade within the shortest time possible.
   2. Until you see another member has been elected to be the primary, then upgrade the binaries of the shutdown primary.
   3. Restart the primary after the upgrade is complete but if you check its status, rs.status(), it might be labeled a secondary.
5. To upgrade for a MongoDB 4.4 Sharded Cluster:
   1. Ensure the balancer has been disabled.
   2. Upgrade the config servers just as the same way you upgraded the replica set.
   3. Upgrade the shard using the corresponding procedure i.e, replica set or a standalone.
   4. Upgrade each mongos instance in order.
   5. Re-enable the balancer.

Conclusion

With time data becomes more complex hence requiring advanced database features that can meet database administrators’ specifications. MongoDB does not fall back on this since it always releases database versions with either fixed bugs or newly integrated features. It is recommended to always upgrade to the latest MongoDB version for maximum performance. Nevertheless, before making an upgrade one needs to check the release notes for the version you want to upgrade to if it is compatible with your system. Upgrading the corresponding MongoDB drivers is also advisable.