Update MongoDB without Service Issues

Welcome to another day at Aleson ITC’s blog, the best Data blog in the industry.

In today’s post, we continue the trend of the previous week, the updates. Today, we’re going to put the updates into practice with a demo in a MongoDB environment.

In this article, we will see how we can achieve a non-stop service upgrade thanks to the high availability offered by MongoDB, the replicaSets.

Upgrade Scenario

Before starting with the demonstration, I am going to expose the scenario I used to perform the upgrade.

Upgrading a secondary node

Now we will connect to the first secondary node. And we will execute the following command to TURN OFF the instance.

db.adminCommand({ shutdown : 1 })

From another node, if we execute the command: rs.status() we will see that the node we have just shut down has no connection with the replicaSet. A message with information about this should appear.

However, we can also verify that the node is off by checking the status of the service in our operating system.

After verifying that we have correctly shut down the instance, we will proceed to run the installation package of version 6.0.5, which is currently the latest version.

Next, we will choose the custom option to apply the installation in the path where we have the log file and the database files.

In the attached image it offers us a default path to make the update, but later (image below) we can indicate where we want it to be updated. That is to say, if we have the .log file in L:\ we will choose that path for the Log Directory.

A window will pop up where we will be able to see the progress of the update.

Update verification

Next, we run rs.status() to see the status of the updated node in the replicaSet.

En el caso que esté en un estado de RECOVERY, esperaremos hasta que finalice y observemos que está In case it is in a RECOVERY state, we will wait until it is finished and observe that it is in a SECONDARY state.

We verify that the corresponding version has been installed on the node.

We will act in the same way in all the secondary nodes that we have in the replicaSet.

Updating the primary node

The procedure with the Primary node shares similarities with the one seen above, except for the first step.

Before shutting down the primary, we will have to perform a failover, i.e., we will become a secondary and a secondary will become the primary.

Executing the rs.stepDown() command from the primary node will perform the failover.

Now the roles will have changed as shown in the following images:

Como vemos, el nodo con IP 10.0.0.5 es el secundario y el nodo con IP 10.0.0.4 no está disponible debido As we can see, the node with IP 10.0.0.5 is the secondary node and the node with IP 10.0.0.4 is not available because after the failover we will have shut it down as we have done before.

Once the node has been updated, we do another failover from the primary node to return to the initial configuration, so each node has its corresponding role.

Update ReplicaSet compatibility

Finally we will update the compatibility version of the ReplicaSet from the primary node with the following command:

db.adminCommand( { setFeatureCompatibilityVersion : "6.0" } )

Next, to verify that it has been updated we will run:

db.adminCommand( { getParameter : 1, featureCompatibilityVersion : 1 } )

And we would have finished the update of our MongoDB environment without service downtime.

To update an older version in a MongoDB environment than a 5.0 version, we will have to go step by step, that is to say, let’s suppose we have a 4.0 version, first we will update to 5.0 and then we will go to 6.0.

I hope it has been helpful for you to update and improve your MongoDB database.

If you like this post, check our latest posts:

How to create Cost Alerts in Microsoft Azure

The importance of SQL Server Updates

Discover SQL Server 2022 Query Store Hints

If you have performance problems and need to optimize your MongoDB or SQL Server BBD, Aleson ITC can help you.