...

CentOS/Redhat - Process for Upgrading MongoDB 3.4 Standalone to MongoDB 4.2 Standalone

Table of Contents

The Process

The process is structured as follows:

1. Prerequisites
2. Upgrade Preparation
3. Upgrade from MongoDB 3.4 to MongoDB 4.2
4. Services Restart
5. Clean-up

Prerequisites for Upgrading MongoDB 3.4 to MongoDB 4.2

As MongoDB 3.4 is out of support customers are wanting to upgrade their NMIS installation to newer in support releases. This document outlines the process to bring MongoDB up to version 4.2. There are a series of prerequisites that determine the type of update required. This document outlines the process for MongoDB Standalone.

There are 4 prerequisites to confirm:

• Operating System
• MongoDB Version
• MongoDB Storage Engine
• NMIS and Modules for Mongo 4.2

Supported Operating Systems

For more information on Opmantek product dependencies, please see Product Compatibility.

MongoDB 3.4 Installed and Running

Verify by running (with your mongodb <username> and <password>)

This command does not do anything however, the output will show us the running shell and server that is running.

...

mongo -u <username> -p <password> --authenticationDatabase=admin --eval 'quit()' | grep MongoDB

Result will look like below, we are looking for the two version numbers to be 3.4.x

If the versions do not match there may be an issue with your running installation and you should not proceed until this is resolved.

...

MongoDB shell version v3.4.24
MongoDB server version: 3.4.24

MongoDB Storage Engine

Verify storage engine by running

...

mongo -u <username> -p <password> --authenticationDatabase=admin --quiet --eval 'db.serverStatus().storageEngine'

The "name" line should have "wiredTiger" in order to proceed.

...

{
        "name" : "wiredTiger",
        "supportsCommittedReads" : true,
        "readOnly" : false,
        "persistent" : true
}

If this mongo cli command does not work you can try the following to determine the storage engine in use

Example correct log output - notice the log entry declares the storage engine to be using "wiredTiger"

If the system is not using wiredTiger the data migration process should follow a different process. Refer to the following link.

https://www.mongodb.com/docs/v4.2/tutorial/change-standalone-wiredtiger/

Upgrade NMIS and Modules for Mongo 4.2

NMIS and Modules must be updated to versions that support MongoDB v4.2 before upgrading MongoDB to v4.2. These releases are backwards compatible with MongoDB v3.4.

Minimum releases for MongoDB 4.2 are:

• NMIS 9.4.0
• opAddress 2.2.0
• opCharts 4.4.0
• opConfig 4.4.0
• opEvents 4.2.0
• opHA 3.5.0
  

You can determine the versions you are running by browsing to:

https://<yourserveraddress>/omk/

You should follow the standard upgrade process for each of these packages, which is handled by the Opmantek Installer.

Preparation

The preparation phase includes 3 sections

1. System Snapshot/Backup
2. Upgrade to latest stable release packages
3. Shutdown all OMK Daemons

This is to be done in this specific sequence.

System Snapshot/Backup

For System Snapshots and Backups you will need to refer to the documentation for your environment.

If the information on your system, or stability of the system is critical to your business it is important to retain a working backup. It is important that you have confirmed that you backups can be restored.

Options:

• Full system backups, including Operating System and Data - Contact your IT department, Vendor Support, or Integrator
• Virtual Machine Snapshots - Refer to the solution guides for the environment
• Database Dump - MongoDB documentation: https://www.mongodb.com/docs/database-tools/mongodump/

Upgrade Linux Packages

After completing the snapshot/backup follow your Linux instructions for upgrading and checking the sanity of the package system.

An example of the update/upgrade cycle for Ubuntu Linux is as follows:

...

apt-get update && apt-get upgrade -y

Check for any errors and address as required.

Once this step is completed you may optionally reboot the system. This can clear out any memory leaks and instabilities in the system that occur due to long uptimes.

Shutdown All OMK Daemons

Prior to commencing into the MongoDB upgrade cycles it is required to shutdown all OMK processes.

The following commands are used to complete this task

...

/usr/local/omk/bin/checkomkdaemons.sh stop
systemctl stop nmis9d

These commands offer minimal feedback, confirm that the nmis9d process has halted as follows:
Example Command and Output

...

user@servername:~/installers# systemctl status nmis9d
● nmis9d.service - Opmantek NMIS9 Daemon
     Loaded: loaded (/etc/systemd/system/nmis9d.service; enabled; vendor preset: enabled)
     Active: inactive (dead) since Fri 2022-07-01 00:31:59 UTC; 1min 31s ago
    Process: 8852 ExecStart=/usr/local/nmis9/bin/nmisd (code=exited, status=0/SUCCESS)
   Main PID: 8856 (code=exited, status=0/SUCCESS)
      Tasks: 0 (limit: 9528)
     Memory: 26.4M
     CGroup: /system.slice/nmis9d.service
 
Jul 01 00:30:14 ferny systemd[1]: Starting Opmantek NMIS9 Daemon...
Jul 01 00:30:15 ferny systemd[1]: Started Opmantek NMIS9 Daemon.
Jul 01 00:31:58 ferny systemd[1]: Stopping Opmantek NMIS9 Daemon...
Jul 01 00:31:59 ferny systemd[1]: nmis9d.service: Succeeded.
Jul 01 00:31:59 ferny systemd[1]: Stopped Opmantek NMIS9 Daemon.

Upgrade from MongoDB 3.4 to MongoDB 4.2

You should follow the standard upgrade process for MongoDB which requires you to upgrade through each step, from 3.4 → 3.6 → 4.0 → 4.2

This completes the in-situ upgrade of MongoDB 3.4 to 4.2 

Restart All OMK Daemons

Now the MongoDB upgrade is complete, you can start all the NMIS and OMK processes.

The following commands are used to complete this task

...

/usr/local/omk/bin/checkomkdaemons.sh start
systemctl start nmis9d

You can now browse to your instance of NMIS:

https://<yourserver>/omk

You will get a screen similar to the following which will give you a status on all installed services:

Image Removed