MongoDB replica sets and sharding
You build a replica set and manage elections, read preferences and failover, then build a sharded cluster, choose a shard key and apply balancing and resharding.
Level 401 · 17 lessons · 15 practice labs
Lessons
Replica sets
- Deploying a three-member replica set
- Member settings: priority, hidden and delayed members
- Elections and failover
- Read preference
- Oplog size and resyncing
- Rolling maintenance and upgrades
- Short task: keep writes safe while the primary falls
Sharding
- Sharded cluster architecture: mongos and config servers
- Choosing a shard key
- Ranged and hashed sharding
- The balancer and chunks
- Zones and data location
- Resharding
- Short task: shard a growing collection
Operations
- Targeted and scatter-gather queries
- Backups in a sharded cluster
- Capstone: design a cluster for a global application
Practice labs
- Deploy a three-member replica set: Start three mongod processes on separate ports, form a replica set and watch the primary election.
- Add a hidden member for reporting: Add a hidden, non-electable member to carry reporting queries and confirm the app does not see it.
- Undo a bad delete with a delayed member: Recover a collection deleted by mistake on the primary from the data on a one-hour delayed member.
- Bring down the primary and watch the election: Shut down the primary, time the election and see the app reconnect.
- Route reads to secondaries: Route a reporting service's reads to secondaries with secondaryPreferred and show the stale read risk.
- Keep writes safe while the primary fails: Tune write concern and retryable writes in a constantly writing app and prove no record is lost when the primary fails.
- Calculate the oplog window: Calculate how many hours of changes the oplog holds at the current write rate.
- Resync a member that fell behind: Rejoin a secondary that fell outside the oplog window with an initial sync.
- Upgrade the set with a rolling restart: Move the whole set to a new version by stepping down secondaries then the primary, without interrupting the app.
- Inspect a sharded cluster's layout: Use sh.status to list shards, config servers and which collections are sharded.
- Change a key that creates a hot shard: Show that all writes go to one shard on a collection sharded by an increasing date and propose a better key.
- Reshard a collection with a new key: Replace a poorly chosen shard key with resharding and watch the app keep working throughout.
- Tell targeted from scatter-gather queries: Use explain to tell which queries go to one shard and which to all shards.
- Fix an unbalanced shard with the balancer: Measure data spread on a cluster whose balancer was left off, set a maintenance window and watch balancing.
- Keep European data on the European shard: Pin customer data to shards by country code with zones and verify new records land in the right place.
About this course
You build a replica set and manage elections, read preferences and failover, then build a sharded cluster, choose a shard key and apply balancing and resharding.
What you will learn
- Replica sets
- Sharding
- Operations
Prerequisites
You should have practised the topics of the same path up to level 301.
Lab environment
Lessons run in your own Kali Linux terminal in the browser, connected to a private lab network. Nothing to install.
Frequently asked questions
- Is this course right for my level?
- The course is at level 401; it assumes you know the topics of the lower-level courses.
- Is there anything to install?
- No. Every lesson runs in your own lab environment that opens in the browser.
- How do lessons work?
- Each lesson has 8 to 10 steps and a short quiz. Early steps show the command to type, later steps give less help; if two attempts fail, the solution opens.
- Can I try it for free?
- Yes. The first three lessons of every course are free.