MongoDB Op Manager

Current Supported Versions (LTS and Rapid Releases): 

Version Type Release Date End of Life (EOL)

7.0 Rapid Aug 2023 Aug 2025

6.0 LTS Jul 2022 Jul 2026

5.0 LTS Jul 2021 Jul 2024 (EOL)

Versioning Policy Summary:

LTS (Long-Term Support) versions are maintained for 4 years.
Rapid releases are supported for only 2 years.

MongoDB 6.0 (LTS) – Best Choice for Stability

• LTS version (supported until July 2026)

• Fully supported by MongoDB Ops Manager

• Ideal for enterprise/mission-critical applications

• Supports features like:

  • Time Series collections

  • Change streams enhancements

  • Aggregation improvements

  • Shard key refinements

Can migrate MongoDB from 4.4 directly to 6.0 using MongoDB Ops Manager, but with strict conditions. 

Yes, you can migrate MongoDB from 4.4 directly to 6.0 using MongoDB Ops Manager, but with strict conditions.

Here’s a breakdown of what you need to know and how to safely perform a direct upgrade from MongoDB 4.4 to 6.0 using Ops Manager.

Is Direct 4.4 → 6.0 Upgrade Supported?

Yes, MongoDB supports direct upgrade from 4.4 → 6.0, only if you:

• Are running MongoDB Enterprise Edition

• Use a compatible Ops Manager version (v6.0 or later)

• Meet all preconditions and compatibility checks

Supported Direct Upgrade Paths (per MongoDB docs)

From Version To Version Direct Upgrade Supported

4.4 5.0 ✅ Yes

5.0 6.0 ✅ Yes

4.4 6.0 ✅ Yes (only for Enterprise with checks passed)

Pre-Upgrade Checklist (Mandatory)

Before using Ops Manager to upgrade MongoDB 4.4 → 6.0, check the following:

Phase 1: Pre-Upgrade Preparation 

1. Upgrade to Latest Patch of 4.4

Ensure all nodes are on the latest 4.4 patch (e.g., 4.4.25+)

Ops Manager → Deployment → MongoDB Processes → Version → Upgrade

Verify Feature Compatibility Version (FCV)

mongo --eval 'db.adminCommand({ getParameter: 1, featureCompatibilityVersion: 1 })'

1. MongoDB Binary Compatibility

• Upgrade to the latest 4.4 patch (e.g., 4.4.25 or above)

• Upgrade MongoDB Tools (mongoimport, mongodump, etc.) to a version that supports 6.0

2. Feature Compatibility Version (FCV)

• Current FCV must be 4.4 before upgrade

After upgrade, set FCV to 6.0 using:
db.adminCommand({ setFeatureCompatibilityVersion: "6.0" })

3. Disable Balancer and Backups

• Pause balancer in sharded clusters

• sh.stopBalancer()

• Stop scheduled backups

4. Backup the Cluster

• Always take a full backup using Ops Manager Backup or mongodump/snapshot

5. Check Incompatible Parameters/Features

• Review deprecations between 4.4 → 6.0

  • Example: noTableScan parameter removed

  • TLS configuration format changes

🛠️ Steps to Upgrade via Ops Manager

1. Log in to Ops Manager UI

2. Go to Deployment > Processes

3. Select the MongoDB 4.4 deployment

4. Choose Upgrade MongoDB

5. Select version 6.0.x

6. Ops Manager will:

   • Download and install binaries

   • Restart MongoDB nodes safely (rolling upgrade)

7. After upgrade:

   • Run setFeatureCompatibilityVersion("6.0")

   • Re-enable balancer, backups

❗ Caution

Area Recommendation

Sharded clusters Upgrade mongos and all shards before FCV bump

Replica sets Upgrade secondaries first, then primary

Automation Must use Ops Manager Automation Agents ≥ 6.x

📘 Official References

• MongoDB 6.0 Upgrade Docs

• Ops Manager Upgrade Path

If you want a step-by-step upgrade checklist tailored to your cluster, share your:

• MongoDB version

• Deployment type (replica set/sharded)

• Ops Manager version

• Backup method used (Ops Manager backup or external)

Services

Node Type Service Name Port

Config Server mongod-cfg 27019

Shard Server mongod-shard1 27018

Mongos Router mongos 27017

What are the key features of Ops Manager? 

• Deployment automation (install, upgrade, scale)

• Continuous backup and point-in-time recovery

• Performance monitoring and alerting

• Security and access control integration

• Integration with LDAP, Active Directory

• Role-based access control (RBAC)

• Custom alerts and monitoring dashboards

How is Ops Manager different from MongoDB Atlas?
Answer:

Feature Ops Manager   MongoDB Atlas

Deployment On-premises or private cloud Fully-managed cloud

Control Full control over the stack Limited by provider abstraction

Backup Snapshot-based and PITR Fully managed with PITR

Security Custom on-prem policies Cloud provider-managed

What components are needed to deploy Ops Manager? 

• Ops Manager Application Server

• MongoDB for Ops Manager's application database

• Backup Daemon (if backup is enabled)

• Monitoring Agent

• Automation Agent

• Backup Agent (if used)

How does MongoDB Ops Manager automation work?

Ops Manager uses the Automation Agent installed on each managed host. The agent pulls instructions from the Ops Manager application and performs actions like deploying mongod/mongos processes, resizing replica sets, or applying configuration changes. 

Describe the backup mechanism used by Ops Manager. 

• Uses Backup Agents to create snapshots.

• Snapshots are stored in block storage or an NFS shared directory.

• Supports point-in-time recovery (PITR).

• Continuous backup is achieved by capturing oplog data between snapshots.

What is the role of the Monitoring Agent?

The Monitoring Agent collects performance metrics (CPU, memory, I/O, locks, connections, etc.) from MongoDB instances and sends them to Ops Manager for visualization and alerting. 

How does Ops Manager integrate with LDAP or AD?

Ops Manager can be configured to use LDAP/AD for:

• User authentication

• Authorization

• Role-based access control (RBAC)

Configuration involves specifying bind DN, base DN, filters, and optionally using TLS for secure communication.

Storage Engines for Self-Managed Deployments :

The storage engine is the component of the database that is responsible for managing how data is stored, both in memory and on disk 

➤ WiredTiger Storage Engine (Default)  WiredTiger is the default storage engine and is recommended for new deployments. WiredTiger provides a document-level concurrency model, checkpointing, and compression, among other features.

In MongoDB Enterprise, WiredTiger also supports Encryption at Rest. See Encrypted Storage Engine.

➤ In-Memory Storage Engine :  An In-Memory storage engine is available in MongoDB Enterprise. Rather than storing documents on-disk, it retains them in-memory for more predictable data latencies.

What are the best practices for Ops Manager backup configuration?

• Use dedicated backup storage (NFS or S3-compatible storage).

• Configure regular snapshot intervals (e.g., hourly/daily).

• Enable PITR for mission-critical workloads.

• Ensure oplog size is adequate for PITR window.

• Secure backup daemon and storage using TLS and IAM policies.

How can you scale MongoDB deployments using Ops Manager? 

• Use Automation Agent to add shards or replica set members.

• Resize instance types (CPU/RAM) via UI or API.

• Schedule rolling upgrades.

• Use tags and groups to manage hosts at scale.

What’s the difference between the Automation Agent and Backup Agent? 

Agent Purpose

Automation Agent Manages deployment lifecycle (create, upgrade, reconfigure)

Backup Agent Captures snapshots and oplog for backup purposes

Can you use Ops Manager in air-gapped environments?

Yes. Ops Manager is ideal for air-gapped or regulated environments where you need to run MongoDB entirely on-prem. You can deploy it without internet access, using local repositories and NTP servers. 

How do you monitor a MongoDB Replica Set in Ops Manager? 

• Install Monitoring Agent on each replica node

• Visualize key metrics: replication lag, election status, replication window

• Set alerts for primary changes, lag thresholds, or heartbeat failures

Explain how alerting works in Ops Manager.

• Supports predefined and custom alerts

• Alerts can be triggered based on thresholds (e.g., CPU > 80%)

• Notifications via email, SMS, PagerDuty, Slack, etc.

• Alerts can be suppressed during maintenance windows

How do you perform a rolling upgrade of MongoDB via Ops Manager? 

• Select cluster or replica set

• Click “Upgrade” and select version

• Ops Manager upgrades nodes sequentially

• Ensures zero downtime using rolling upgrade policy

• Compatible with major and minor version changes

Default Port:

• 27017 if mongod is not a shard member or a config server member

• 27018 if mongod is a shard member

• 27019 if mongod is a config server member

Agent Debug Checklist (Daily Use) 

Check Command / Action

Agent Status systemctl status mongodb-mms-*

Restart Agent systemctl restart mongodb-mms-*

View Logs tail -f /var/log/mongodb-mms-*/*.log

Ping Ops Manager curl -k https://<ops-manager-host>/api/

MongoDB Access mongo -u user -p --authenticationDatabase admin

TLS Validation openssl s_client -connect host:port

Key MongoDB Daemons : In MongoDB, a daemon is a background process that runs continuously to provide core functionality. Here's a breakdown of MongoDB-related daemons: 

Daemon Name Command Description

mongod mongod Primary MongoDB Server Daemon. 

   Handles database requests, manages data storage, replication, and sharding.

mongos mongos Query Router for Sharded Clusters. Acts as a middleware between client 

  applications and sharded database deployments.

mongo (legacy) mongo MongoDB Shell Client (deprecated in newer versions). Used to connect to 

MongoDB instances interactively. Replaced by mongosh.

mongosh mongosh Modern MongoDB Shell. CLI to interact with MongoDB servers. 

  Does not run as a daemon.

mongodb-mms-automation-agent Agent Runs in Ops Manager/Atlas environments for automation tasks like backups, 

                                                                                                monitoring, scaling, etc.

mongodb-mms-monitoring-agent   Agent                        Collects metrics and performance data.

mongodb-mms-backup-agent            Agent                       Manages backups in Ops Manager setups.

Starting a mongod process:      mongod --config /etc/mongod.conf

Starting a mongos for sharded cluster:            mongos --configdb configReplSet/host1:port1,host2:port2,host3:port3

Systemd/Linux Services: mongod is often managed via system service: 

Background Behavior                                          sudo systemctl start mongod

                                                                       sudo systemctl status mongod

Daemon Logs:   Usually found at /var/log/mongodb/mongod.log. 

Corrected MongoDB Tools & Their Descriptions 

Tool                              Correct Name                                                          Description

mongoimport                   ✔️ Imports data into MongoDB from a JSON, CSV, or TSV file.

bsondump   ✔️ Converts BSON files into human-readable JSON format.

mongodump           ✔️ Creates a binary export (backup) of the contents of a database.

mongoexport         ✔️ Exports data from a MongoDB collection to a JSON or CSV file.

mongofiles   ✔️ Interacts with GridFS to upload/download/delete files stored in MongoDB.

mongorestore   ✔️         Restores a database from a binary dump created by mongodump.

mongostat   ✔️ Real-time statistics about MongoDB server operations (like top for MongoDB).

mongotop            ✔️ Shows the time a MongoDB instance spends reading and writing data per collection.

Common Ops Manager CLI/API Operations:  

Start Monitoring Agent:            ./mongodb-mms-monitoring-agent -f /etc/mongodb-mms/monitoring-agent.config

Start Backup Agent:                 ./mongodb-mms-backup-agent -f /etc/mongodb-mms/backup-agent.config

API Call: List All Projects      curl -u "username:apikey" \  "https://<ops-manager-url>/api/public/v1.0/groups"

Check Agent Logs                      tail -f /var/log/mongodb-mms/monitoring-agent.log

MongoDB Replica Set Commands 

Initialize Replica Set:   

rs.initiate({

  _id: "rs0",

  members: [

    { _id: 0, host: "host1:27017" },

    { _id: 1, host: "host2:27017" },

    { _id: 2, host: "host3:27017" }

  ]

})

Check Replica Set Status: 

 rs.status()

Add a New Member:  rs.add("newhost:27017")

Reconfigure Replica Set: 

cfg = rs.conf()

cfg.members[0].priority = 2

rs.reconfig(cfg)

MongoDB Sharding Commands  Sharding allows MongoDB to scale horizontally by distributing data across multiple shards. 

Enable Sharding on a Database:  sh.enableSharding("myDatabase")

Shard a Collection: sh.shardCollection("myDatabase.myCollection", { userId: 1 })

Add a Shard:  sh.addShard("rs1/host1:27017,host2:27017,host3:27017")

View Sharding Status: sh.status()

Backup strategy for MongoDB:

• ✅ MongoDB Ops Manager (for enterprise-grade, point-in-time backup and automation)

• ✅ mongodump/mongorestore (for simpler, manual backup/restore scenarios)

🛡️ PART 1: MongoDB Ops Manager Backup Strategy

• Production-grade, managed clusters (Ops Manager or MongoDB Atlas)

• Need for Point-in-Time Recovery (PITR) and automated scheduling

• Backing up sharded clusters and replica sets

🔁 Ops Manager Backup Types

Backup Type Description

Continuous Real-time, incremental backup with PITR capability (uses oplog)

Snapshot-Based Full snapshot taken periodically + oplog slices

Blockstore Backup using filesystem snapshots (e.g., with LVM, EBS, NFS)

Filesystem/Head DB Local DB snapshot — typically for Ops Manager instances themselves

🛠️ Backup Setup (Automation Agent)

1. Install Ops Manager Backup Agent on MongoDB nodes

# Example

sudo mkdir -p /opt/mongodb/mmsbackup

sudo tar -xzf mongodb-mms-backup-agent-latest.tar.gz -C /opt/mongodb/mmsbackup

2. Configure agent with backup-agent.config:

mmsBaseUrl=https://<opsmanager-host>:443

mmsGroupId=<GROUP-ID>

logFile=/var/log/mongodb-mms-backup-agent.log

logLevel=INFO

mmsApiKey=<API-KEY>

3. Register Agent in Ops Manager UI

• Navigate to Admin → Backup → Agents

• Add Backup Agent and assign to deployment

4. Enable Backups via UI

• Go to Projects → Deployment

• Click Backup → Enable Backup

• Choose Snapshot interval, Oplog retention, and Backup store

📆 Recommended Backup Schedule

Component Frequency Type

Config Servers Daily Snapshot + Oplog

Shard Servers Hourly/Continuous Continuous backup

mongos (router) Not required No data stored

💡 Ops Manager PITR Restore Steps

1.Go to Ops Manager UI > Deployment > Backup
2.Choose the snapshot or time point
3.Click Restore, choose:
Download to staging
Restore directly to cluster
Restore to different cluster (for testing)

🧪 PART 2: mongodump / mongorestore Strategy

• Development, test, or ad hoc manual backup

• Lightweight clusters

• No need for PITR

🔄 Backup with mongodump

A. Full DB Backup (Standalone or Replica Set)

mongodump --host <host>:<port> --out /backups/backup-$(date +%F)

B. With Authentication

mongodump --uri "mongodb://admin:password@host1:27017/?authSource=admin" --gzip --archive=/backups/backup.gz

C. For Sharded Cluster

• Run against mongos
  mongodump --host mongos-router:27017 --out /backup/sharded

🔁 Restore with mongorestore

mongorestore --uri "mongodb://admin:password@mongos:27017" --gzip --archive=/backups/backup.gz

⚠️ Notes on mongodump

• Doesn’t support point-in-time recovery

• Slower than snapshot methods

• Cannot backup local or oplog.rs directly

Use --oplog for replica set consistent dump:
mongodump --oplog --out /backup/repl-backup

✅ Recommended Strategy Matrix

Use Case Tool Backup Type Frequency Recovery Time

Enterprise, Production Ops Manager Snapshot + PITR Continuous/Daily Fast (PITR)

Dev/Test mongodump Logical Backup Ad hoc / Manual Moderate

Sharded Cluster Ops Manager/mongodump Shard-aware backup Scheduled Depends

📦 Optional: Automate with Cron + Shell Script

#!/bin/bash

BACKUP_DIR="/backup/mongodump-$(date +%F)"

mkdir -p $BACKUP_DIR

mongodump --host localhost --port 27017 --gzip --out $BACKUP_DIR

find /backup -type d -mtime +7 -exec rm -rf {} \;

Add to cron:

0 2 * * * /scripts/mongodump_daily.sh >> /var/log/mongodump.log 2>&1

📎 Want Next?

• Restore testing strategy for backups?

• Custom retention policy for Ops Manager?

• Ops Manager High Availability setup?

• Backup strategy using Cloud (e.g., AWS S3/NFS snapshot)?