As applications grow, a single MongoDB server eventually can't keep up — either it becomes a single point of failure, or it simply runs out of capacity to store and serve data. MongoDB solves these two problems with two distinct mechanisms: replication for high availability, and sharding for horizontal scale. This tutorial covers both in depth, along with backup and disaster recovery strategies.
Information
📖 1. Introduction
Replication protects against data loss and downtime by keeping multiple copies of data in sync. Sharding distributes data across multiple servers to handle datasets and workloads too large for a single machine. These techniques are complementary — a production sharded cluster is typically built from multiple replica sets.
🛡️ 2. High Availability
High availability means the database stays accessible even when individual servers fail. MongoDB achieves this through replica sets, which maintain multiple synchronized copies of the same data.
Tip
👥 3. Replica Sets
A replica set is a group of mongod instances that maintain the same data set. One member acts as the primary, accepting all writes, while the others act as secondaries, replicating data from the primary.
Initializing a three-member replica set
// Initiating a replica set from the shell
rs.initiate({
_id: "rs0",
members: [
{ _id: 0, host: "mongo1:27017" },
{ _id: 1, host: "mongo2:27017" },
{ _id: 2, host: "mongo3:27017" }
]
});👑 4. Primary Node
The primary is the only member that accepts write operations. All changes are recorded in its oplog and streamed to secondaries for replication.
Note
🪞 5. Secondary Nodes
Secondaries continuously replicate the primary's data by applying operations from its oplog. They can optionally serve read operations, depending on the configured read preference.
Directing a read to a secondary
// Reading from a secondary
const results = await collection
.find({ status: "completed" })
.readPreference("secondary")
.toArray();⚖️ 6. Arbiter
An arbiter is a lightweight replica set member that participates in elections but holds no data, used to maintain an odd number of voting members without the cost of a full data-bearing node.
Caution
🗳️ 7. Elections
When the primary becomes unreachable, the replica set holds an election among the remaining members to choose a new primary, typically completing in a few seconds.
Important
🔄 8. Automatic Failover
When a primary fails, MongoDB automatically promotes a secondary to primary through an election, allowing the application to resume writes with minimal manual intervention.
Tip
📖 9. Read Preferences
Read preference controls which replica set member(s) serve read operations — trading off consistency for read scalability or reduced latency.
| Mode | Behavior |
|---|---|
| primary | Reads only from the primary (default, most consistent) |
| primaryPreferred | Primary if available, else a secondary |
| secondary | Reads only from secondaries |
| secondaryPreferred | Secondary if available, else the primary |
| nearest | Reads from the member with lowest network latency |
✍️ 10. Write Concerns
Write concern specifies how many replica set members must acknowledge a write before it's considered successful, directly affecting durability guarantees.
Setting a majority write concern
// Require acknowledgment from a majority of members
await collection.insertOne(
{ name: "Mouse" },
{ writeConcern: { w: "majority", wtimeout: 5000 } }
);Warning
⏱️ 11. Replication Lag
Replication lag is the delay between a write occurring on the primary and it being applied on a secondary. Reading from a lagging secondary can return stale data.
Caution
📜 12. Oplog
The oplog (operations log) is a special capped collection on the primary that records every write operation, forming the basis of replication — secondaries continuously tail and apply it.
Inspecting oplog status
// Checking oplog size and window (from the shell)
rs.printReplicationInfo();Note
🔃 13. Initial Sync
When a new or recovering member joins a replica set, it performs an initial sync — copying all data from an existing member before it can begin applying oplog entries.
Tip
🧩 14. Sharding
Sharding partitions a collection's data across multiple servers (shards), each holding a subset of the total dataset, allowing storage and throughput to scale horizontally.
🔑 15. Shard Keys
The shard key is the field (or fields) MongoDB uses to distribute documents across shards. Choosing a good shard key is one of the most consequential decisions in a sharded deployment.
Sharding a collection by customerId
// Enabling sharding and choosing a shard key
sh.enableSharding("shop");
sh.shardCollection("shop.orders", { customerId: "hashed" });Important
🗄️ 16. Config Servers
Config servers store the sharded cluster's metadata — which chunks of data live on which shards — and must themselves run as a replica set for redundancy.
Note
🚦 17. Query Router (mongos)
mongos acts as the entry point for client applications, routing queries to the appropriate shard(s) and merging results transparently — applications connect to mongos as if it were a single database.
Connecting through mongos routers
const client = new MongoClient("mongodb://mongos1:27017,mongos2:27017");🧱 18. Chunk Management
Data within a sharded collection is divided into chunks — contiguous ranges of shard key values — which MongoDB automatically splits and migrates as data grows.
Tip
⚖️ 19. Balancer
The balancer is a background process that migrates chunks between shards to keep data distribution even, running automatically unless explicitly disabled.
Managing the balancer
// Checking balancer status
sh.getBalancerState();
// Temporarily disabling the balancer (e.g. during maintenance)
sh.stopBalancer();Caution
🗺️ 20. Zone Sharding
Zone sharding associates ranges of shard key values with specific shards, commonly used to keep data geographically local for compliance or latency reasons.
Pinning Indian customer data to a specific shard zone
sh.addShardToZone("shard-india", "IN");
sh.updateZoneKeyRange(
"shop.orders",
{ region: "IN", customerId: MinKey },
{ region: "IN", customerId: MaxKey },
"IN"
);📈 21. Scaling Strategies
- Start with replication alone until read/write throughput or dataset size genuinely require sharding.
- Use read replicas (secondary reads) to scale read-heavy workloads before introducing sharding complexity.
- Choose shard keys based on actual query and write patterns, not convenience.
- Consider zone sharding for data residency or latency-sensitive geographic distribution.
💾 22. Backup & Recovery
Regular backups protect against data loss from corruption, accidental deletion, or catastrophic failure — replication alone does not protect against a bad write propagating to every replica.
| Method | Use Case |
|---|---|
| mongodump / mongorestore | Logical backups for smaller datasets |
| Filesystem snapshots | Fast, consistent backups of large datasets |
| Atlas continuous backups | Managed, point-in-time recovery |
Danger
🆘 23. Disaster Recovery
A solid disaster recovery plan defines a target Recovery Point Objective (RPO) and Recovery Time Objective (RTO), and includes regularly tested restore procedures — not just backups that are never verified.
Best Practice
🌟 24. Best Practices
- Run replica sets with an odd number of voting members, ideally spread across failure domains.
- Use w: "majority" write concern for critical data to avoid loss during failover.
- Choose shard keys with high cardinality and even write distribution.
- Monitor replication lag, oplog window, and balancer activity continuously.
- Maintain and regularly test backup and restore procedures.
⚠️ 25. Common Mistakes
- Running a single standalone mongod in production with no replication.
- Choosing a monotonically increasing shard key (like a timestamp), causing hot shard problems.
- Relying on replication alone as a backup strategy.
- Ignoring replication lag when reading from secondaries, leading to stale data surprises.
- Under-provisioning the oplog size, shrinking the window available for secondaries to catch up.
Best Practice
❓ 26. Frequently Asked Questions
A minimum of three data-bearing members is recommended for production, allowing the set to tolerate one member failure while still maintaining a majority for elections.
No. Sharding and replication solve different problems and are typically used together — each shard in a production cluster is usually its own replica set.
Since MongoDB 5.0, resharding is supported, but it's a resource-intensive operation best avoided by choosing the right key upfront.