Select Page

MongoDB 4.0 Upgrade Guide

Datavail | | 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.

12c Upgrade Bug with SQL Tuning Advisor

This blog post outlines steps to take on Oracle upgrade 11.2 to 12.1 if you’re having performance problems. Oracle offers a patch and work around to BUG 20540751.

Megan Elphingstone | March 22, 2017
code

Recover a Table from an RMAN Backup in an Oracle 12c

This blog post will is to show a table restore for one table in a container database

Megan Elphingstone | February 2, 2017
oracle , aws

Oracle Cloud vs Amazon Cloud – Which is right for you?

Choosing the right cloud computing vendor for your database needs is difficult. This blog post takes you through the pros and cons of Oracle vs Amazon Cloud.

Megan Elphingstone | July 20, 2017

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