Mastering MongoDB Clusters: Setup, Monitoring, and Performance Tuning

1. MongoDB Cluster Overview

MongoDB is a distributed file‑based database designed for scalable high‑performance web applications. The most common three‑node cluster components are described below.

1. Cluster components

mongos (router): Entry point for clients; forwards requests to the appropriate shard and merges results.

config server: Stores metadata about sharding and collection layout; usually deployed with multiple instances for redundancy.

shard (mongod): Holds a subset of data; the balancer moves chunks to keep distribution even.

replica set: Provides high availability; consists of a primary and one or more secondaries (and optionally an arbiter).

arbiter: Participates in elections without storing data.

2. MongoDB use cases

Website data – real‑time inserts, updates and queries with replication and horizontal scaling.

Cache layer – high‑performance persistent cache to protect downstream data sources.

Large, low‑value data – cheaper than relational storage for bulk files.

Highly scalable workloads – clusters of dozens or hundreds of servers.

Object/JSON storage – BSON format fits document‑oriented data.

3. Why choose MongoDB

It stores data in BSON, scales horizontally with simple sharding, and delivers strong performance for massive datasets.

2. Cluster Monitoring

1. View storage statistics

Enter a mongos or shard container and run:

docker exec -it mongos bash;
mongo --port 20001;
use admin;
db.auth("root","XXX");

Then execute:

db.stats();

2. View server status

db.runCommand({ serverStatus: 1 });

3. Check replica set members

rs.status();

3. Basic Operations

1. Set and view slow query profiling

# Set slow query threshold
db.setProfilingLevel(1,200);
# View profiling level
db.getProfilingLevel();
# Find recent slow operations
db.system.profile.find({ ns : 'dbName.collectionName'}).limit(10).sort({ ts : -1 }).pretty();

2. Find long‑running operations

db.currentOp({"active" : true,"secs_running" : { "$gt" : 2000 }});

3. Adjust log level and cache size

# Get log level
db.adminCommand({ "getParameter": 1, "logLevel":1});
# Set WiredTiger cache
db.adminCommand({ "setParameter": 1, "wiredTigerEngineRuntimeConfig": "cache_size=4G"});

4. Add or remove replica set members

# List members
rs.status().members;
# Add member
rs.add('127.0.0.1:20001');
# Remove member
rs.remove('127.0.0.1:20001');

5. Enable sharding and shard a collection

# Enable sharding for a database
sh.enableSharding("dbName");
# Shard a collection
sh.shardCollection("dbName.collectionName", { fieldName: 1 });

6. Add or remove shards

# View shard status
sh.status();
# Add shard (replica set or single instance)
db.runCommand({ addshard:"rs1/ip-1:20001,ip-2:20001,ip-3:20001"});
# Remove shard
db.runCommand({ removeShard: "shardName" });
# Refresh router config
db.runCommand("flushRouterConfig");

Note: Removing a shard may require multiple attempts until the state becomes

{"draining": true}

and finally

removeshard

succeeds.

7. Data import / export

# Export
mongoexport -h 127.0.0.1 --port 20001 -u xxx -p xxx -d xxx -c mobileIndex -o XXX.txt
# Import
mongoimport -h 127.0.0.1 --port 20001 -u xxx -p xxx -d xxx -c mobileIndex --file XXX.txt

4. MongoDB Data Migration

1. Migrate a replica set member

Stop the mongod instance (e.g.,

docker stop node

or

db.shutdownServer()

).

Copy the dbPath to the new host.

Start mongod on the new host with the copied data.

Connect to the current primary and reconfigure the set if the host address changed.

cfg = rs.conf();
cfg.members[2].host = "127.0.0.1:27017";
rs.reconfig(cfg);

2. Migrate the primary node

Step down the current primary with

rs.stepDown()

or

replSetStepDown

, then follow the member migration steps.

3. Recover data from another replica set node

Stop the node that needs recovery.

Copy its data files to the target machine.

Start mongod with the copied files.

Add the node back to the replica set with

rs.add()

, then remove the old member.

5. Common Production Issues and Solutions

1. Index creation locks the database

Kill the long‑running operation and rebuild the index in the background:

# Find long operations
db.currentOp({"active": true,"secs_running": {"$gt": 2000}});
# Kill operation
db.killOp(opid);
# Build index in background
db.collectionName.ensureIndex({ fieldName:1 }, { background:true });

2. Uncontrolled memory usage causes process termination

Adjust WiredTiger cache size dynamically:

db.adminCommand({ "setParameter":1, "wiredTigerEngineRuntimeConfig":"cache_size=2G"});

3. Deleting data does not free disk space

Use

compact

on the collection or perform a full resync of a secondary node.

4. High server load

Temporarily remove the secondary from the replica set to free I/O, then address the root cause by adding resources or sharding.

5. Poor shard key choice causes hot spots

Change the shard key or limit migrations to off‑peak windows.

6. Optimization Recommendations

1. Application‑level

Ensure queries use indexes; verify with

explain()

.

Design an appropriate shard key (hash or compound) to avoid hot partitions.

Enable profiling to capture slow operations (

db.setProfilingLevel(1,50)

).

2. Hardware‑level

Keep hot data and indexes within RAM.

Prefer fast file systems such as ext4 or XFS.

3. Architecture‑level

Separate primary and secondary nodes onto different machines to reduce I/O contention.

7. Conclusion

MongoDB delivers high performance and easy scalability, but careful attention to shard key selection, memory sizing, and I/O architecture is essential for optimal operation.

Original source: https://www.jianshu.com/p/f05f65d3a1dc