Select Page

MongoDB 4.0 Upgrade Guide

Author: Hanan Alsahsan | | October 8, 2018

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.
  2. You should upgrade to 4.0 using package manager, if you installed MongoDB from the MongoDB apt, yum, dnf, or zypper repositories.

  3.      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
  2. Connect to Mongo instance and use command sh.stopBalancer() to stop the balancer in the shared cluster.

     

  3.      Upgrade the Config Servers
  4. 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.

     

  5.      Upgrade Shards One by One
  6. 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.

  7.      Upgrade the MongoDB instances
  8. Replace each MongoDB instance running 3.6 binary with the 4.0 binary and restart.

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

  11.      Enable backwards-incompatible 4.0 features
  12. On a MongoDB instance in the admin database, run command db.adminCommand( { setFeatureCompatibilityVersion: “4.0” } ).

  13.      Restart MongoDB instances
  14. 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.

How to Solve the Oracle Error ORA-12154: TNS:could not resolve the connect identifier specified

The “ORA-12154: TNS Oracle error message is very common for database administrators. Learn how to diagnose & resolve this common issue here today.

Vijay Muthu | February 4, 2021

How to Recover a Table from an Oracle 12c RMAN Backup

Our database experts explain how to recover and restore a table from an Oracle 12c RMAN Backup with this step-by-step blog. Read more.

Megan Elphingstone | February 2, 2017

Data Types: The Importance of Choosing the Correct Data Type

Most DBAs have struggled with the pros and cons of choosing one data type over another. This blog post discusses different situations.

Craig Mullins | October 11, 2017

Subscribe to Our Blog

Never miss a post! Stay up to date with the latest database, application and analytics tips and news. Delivered in a handy bi-weekly update straight to your inbox. You can unsubscribe at any time.

Work with Us

Let’s have a conversation about what you need to succeed and how we can help get you there.

CONTACT US

Work for Us

Where do you want to take your career? Explore exciting opportunities to join our team.

EXPLORE JOBS