MongoDB in MongoDB is best learned by connecting the rule to a product catalog or user activity store. Start with the smallest collection query, observe the output, and then add one realistic constraint so the concept becomes practical.
The key habit for this lesson is to watch document shape and index as it changes. That makes the topic easier to debug, easier to explain in interviews, and easier to use in real code without memorizing isolated syntax.
A replica set is a group of MongoDB instances that maintain the same dataset. It provides redundancy and high availability. If the primary node fails, an automatic election promotes one of the secondaries to become the new primary - with no manual intervention required.
| Role | Description |
|---|---|
| Primary | Receives all write operations. Only one primary per replica set at a time. |
| Secondary | Replicates data from the primary via the oplog. Can serve reads (with read preference). |
| Arbiter | Participates in elections but holds no data. Used to break ties in even-numbered sets. |
// Start 3 mongod instances with --replSet flag
// mongod --replSet "rs0" --port 27017 --dbpath /data/rs0
// mongod --replSet "rs0" --port 27018 --dbpath /data/rs1
// mongod --replSet "rs0" --port 27019 --dbpath /data/rs2
// Connect to the first instance and initiate the replica set
mongosh --port 27017
rs.initiate({
_id: "rs0",
members: [
{ _id: 0, host: "localhost:27017", priority: 2 }, // preferred primary
{ _id: 1, host: "localhost:27018", priority: 1 },
{ _id: 2, host: "localhost:27019", priority: 1 }
]
})
// Check replica set status
rs.status()
// Check replica set configuration
rs.conf()
// Add a new member to an existing replica set
rs.add("localhost:27020")
// Add an arbiter
rs.addArb("localhost:27021")
// Remove a member
rs.remove("localhost:27020")// Read Preferences - control where reads are routed
// primary - always read from primary (default, most consistent)
// primaryPreferred - read from primary if available, else secondary
// secondary - always read from a secondary
// secondaryPreferred - read from secondary if available, else primary
// nearest - read from the member with lowest network latency
// Set read preference in connection string
mongosh "mongodb://host1:27017,host2:27018,host3:27019/mydb?replicaSet=rs0&readPreference=secondaryPreferred"
// Set read preference per query
db.users.find({ active: true }).readPref("secondary")
// Write Concern - control acknowledgment level for writes
db.users.insertOne(
{ name: "Alice" },
{ writeConcern: { w: "majority", j: true, wtimeout: 5000 } }
)
// w: 1 - acknowledged by primary only (fast, less safe)
// w: "majority" - acknowledged by majority of replica set (recommended)
// j: true - write must be journaled before acknowledgment
// wtimeout - max milliseconds to wait for write concern// Check replica set status and replication lag
rs.status()
// Look for: members[].optimeDate and members[].lastHeartbeatMessage
// Check oplog size and usage
use local
db.oplog.rs.stats()
db.oplog.rs.find().sort({ $natural: -1 }).limit(1)
// Step down the primary (triggers election)
rs.stepDown()
// Freeze a secondary (prevent it from becoming primary for N seconds)
rs.freeze(120)
// Check if current node is primary
db.isMaster()
// or
rs.isMaster()Use MongoDB when the program needs a clear answer to a specific problem, not because the keyword looks familiar. In a real MongoDB task, first name the input, then name the transformation, then name the output. This small discipline shows whether the topic is being used correctly or only copied from an example.
A reliable practice flow is: create the smallest working collection query, add one normal case, add one edge case such as missing, repeated, empty, or boundary input, and then confirm the result with explain plan and sample documents. If the result surprises you, reduce the code until the behavior is visible again.
The most common trap here is copying the syntax before understanding the behavior. Avoid it by writing one sentence before the code that explains why MongoDB is the right choice. After the code runs, verify the lesson by doing this: change one input and explain the changed output.
Copying the syntax before understanding the behavior.
Write the expected behavior first, then make the example prove it.
Practicing only the perfect input.
Also test missing, repeated, empty, or boundary input before considering the lesson complete.
Looking only at the final output.
Trace document shape and index through each important step.
Use it when the problem matches the behavior shown in the example and when the result can be verified through explain plan and sample documents.
Start with a tiny case, then test missing, repeated, empty, or boundary input. The main warning sign is copying the syntax before understanding the behavior.
Trace document shape and index, predict the result, run the example, and compare your prediction with the actual output.
Explore 500+ free tutorials across 20+ languages and frameworks.