Need suggestions on Mongodb upgrade from 4.0 MMapV1 to Mongodb 4.2 wiredtiger

Hi Team,

Currently, I am using mongo 4.0 MMapV1 in the environment. The setup is in PSA architecture. As Mongo 4.0 will be EoLed in April 2022, so upgrading the setup to mongo 4.2. I have tried to upgrade the setup from Mongo 4.0 MMapV1 to 4.2 Mongo wiredtiger in the test environment. Could not observe any issues. Wanted to upgrade in a production environment now from mongo 4.0 MMapV1 to 4.2 wiredtiger.

Followed below steps for upgrade:
The system has One Primary, One Secondary, and one arbiter
All are running in 4.0 MMAPV1
First Converted Secondary and arbiter to 4.2 in wiredTiger
Moved secondary to Primary, then converted old Primary to 4.2 WiredTiger.

Before upgrading in a production environment, I wanted to get suggestions from the team.

  1. As mongo 4.2 does not support MMapV1, Before upgrade Am I required to move replicasets from mongo 4.0 MMapV1 to Mongo 4.0 wiredtiger? Is it mandatory?
  2. Is upgrading from Mongo 4.0 MMapV1 to Mongo 4.2 wiredtiger the correct way?
  3. Is it really required to change the storage engine from MMapV1 to wiredtiger on Mongo 4.0, then upgrade from 4.0 wiredtiger to 4.2 wiredtiger?
  4. Tuning of parameters required for changing storage engine from MMapV1 to Wiredtiger.

Please provide inputs.


Hi @Sreedhar_N,

For prerequisites and steps for upgrading a replica set from 4.0 to 4.2, please see Upgrade a Replica Set to 4.2 in the MongoDB server documentation.

Since support for the deprecated MMAPv1 storage engine was removed in MongoDB 4.2, upgrading to WiredTiger (default storage engine since MongoDB 3.2) is required before you upgrade:

If your 4.0 deployment uses MMAPv1, you must change the 4.0 deployment to WiredTiger Storage Engine before upgrading to MongoDB 4.2. For details, see Change Replica Set to WiredTiger.

I would remove any MMAP-specific parameters and start with the defaults for WiredTiger unless you have identified specific performance goals or tuning required. I would also thoroughly test with representative data, workloads, and deployment resources in a staging or QA environment so you can identify any changed performance characteristics.

I would strongly consider upgrading to a PSS deployment. For a longer explanation on the consequences of arbiters, please see: Replica set with 3 DB Nodes and 1 Arbiter - #8 by Stennie .

If you prefer to continue with PSA and WiredTiger, please review the PSA 3-member architecture note in the documentation for changing to WiredTiger.