MongoDB 4.0 Upgrade Guide

Why upgrade to MongoDB 4.0? There are several reasons to keep upgrading MongoDB. Newest version offers multiple new features, fixes previous version bugs/ issues, and improves security.

MongoDB 4.0 has been available for download since June 27, 2018. The new release offers new features designed to help you work with data, helping you place it anywhere you need it. Feature highlights include:
 

•        Multi-document ACID transactions
•        Nonblocking secondary replica reads
•        Data type conversions
•        SCRAM-SHA-256 authentication
•        Up to 40% faster shared migrations
•        Take an up-to-date backup of your data set using one of the MongoDB Backup Methods that meets your needs.
•        Plan the upgrade during a predefined maintenance window.
•        Check MongoDB documentation for compatibility issues specific to your release.
•        Test your upgrade procedures in the staging environment to ensure compatibility.

Before Upgrading

Prerequisites

1.      If you’re using an older version of MongoDB, you must successively upgrade to MongoDB 3.6 before moving to 4.0.
2.      If your deployment has user credentials stored in MONGODB-CR schema, upgrade to Salted Challenge Response Authentication Mechanism (SCRAM) before moving to MongoDB 4.0.
3.      Starting in version 4.0, MongoDB removes support for the $isolated operator. Before upgrading you need to recreate the index or views without $isolated operator.
4.      The 3.6 instance must have featureCompatibilityVersion set to 3.6.

 
Prerequisites to Replica Set and Shredded Cluster
 

1.      All replica set members must be using version 3.6.
2.      You must upgrade replica set protocol version 0 to pv1 as protocol version 0 pv0 is deprecated in MongoDB 4.0.
3.      If your deployment uses master-slave replication, you must upgrade to a replica set as master-slave replication is deprecated in MongoDB 4.0.
4.      No replica set member should be in ROLLBACK or RECOVERING state.

Upgrade Procedure

Download 4.0 Binaries

1.      Package Manager – The preferred method for upgrading MongoDB to 4.0.

You should upgrade to 4.0 using package manager, if you installed MongoDB from the MongoDB apt, yum, dnf, or zypper repositories.

2.      Manually

Use MongoDB Download Center to download binaries, if you didn’t use MongoDB repositories.

Upgrade Process for standalone MongoDB

When you upgrade a standalone MongoDB, the MongoDB server is down during the upgrade process.

1.      Shut down the MongoDB instance and replace the 3.6 binary with the 4.0 binary followed by restart the member.
2.      Enable backwards-incompatible 4.0 features by executing db.adminCommand( { setFeatureCompatibilityVersion: “4.0” } )

Upgrade Process for Replica Set MongoDB

To upgrade a replica set from MongoDB 3.6 to 4.0 start by upgrading secondary members one at a time and finishing with the primary.

1.      Shut down the MongoDB instance and replace the 3.6 binary with the 4.0 binary followed by a member restart.
2.      Wait for the member to update to SECONDARY state before upgrading the next secondary member.

Upgrade the Primary

1.      Execute rs.stepDown() command on the current primary to force an election of a new primary.
2.      Once the primary has stepped down and another member has become the new primary start upgrading the original primary.
3.      Shut down the original primary instance and replace the 3.6 binary with the 4.0 binary followed by the member restart.
4.      Enable backwards-incompatible 4.0 features by executing db.adminCommand( { setFeatureCompatibilityVersion: “4.0” } )

Upgrade Process for Shared Cluster

1.      Stop balancer

Connect to Mongo instance and use command sh.stopBalancer() to stop the balancer in the shared cluster.

 

2.      Upgrade the Config Servers

To upgrade config servers, start with secondaries member one at a time:

a)    Stop the secondary MongoDB instance and replace the 3.6 binary with the 4.0 binary.

b)    Start the 4.0 binary with the –configsvr, –replSet, and –port.

c)     Wait for the member to recover to SECONDARY state before upgrading the next secondary member.

Upgrade primary

a)    Execute rs.stepDown() command on the current primary to force an election of a new primary.

b)    Once the primary has stepped down and another member has become the new primary start upgrading the original primary.

c)     Start the 4.0 binary with the –configsvr, –replSet, –port, and –bind_ip options.

 

3.      Upgrade Shards One by One

For each shard replica set:

Upgrade the secondary members of the replica set one after the other:

a)    Shut down the secondary MongoDB instance and replace the 3.6 binary with the 4.0 binary.

b)    Start the 4.0 binary with the –shardsvr, –replSet, and –port. Include any other options as used by the deployment.

c)     Wait for the member to recover to SECONDARY state before upgrading the next secondary member.

Upgrade primary

a)    Execute rs.stepDown() command on the current primary to force an election of a new primary.

b)    Once the primary has stepped down and another member has assumed PRIMARY state another server becomes the new primary start upgrading the original primary.

c)     Start the 4.0 binary with the –shardsvr, –replSet, –port, and –bind_ip options.

4.      Upgrade the MongoDB instances

Replace each MongoDB instance running 3.6 binary with the 4.0 binary and restart.

5.      Re-enable the balancer

Connect to the MongoDB instance and use command sh.setBalancerState() to re-enable the balancer.

6.      Enable backwards-incompatible 4.0 features

On a MongoDB instance in the admin database, run command db.adminCommand( { setFeatureCompatibilityVersion: “4.0” } ).

7.      Restart MongoDB instances

Restart all MongoDB instances to pick up the changes in the fundamental consistency behavior.

Now that you know all the steps involved, you can easily upgrade your environment to MongoDB 4.0. Datavail can also help you make the move. Learn about Datavail’s database upgrade services now.