Chunks, Balancing & Zones

## The unit of distribution When you shard a collection, MongoDB partitions the *value space* of the shard key into contiguous, non-overlapping intervals. Current documentation calls them **ranges**; interviews and older tooling call them **chunks**. Each interval is half-open — `[min, max)`, lower bound included, upper excluded — so the intervals tile the whole space with no gaps and no overlap. A freshly sharded collection has one range spanning `MinKey` to `MaxKey`, two special BSON types that sort below and above every other value. Ownership is exclusive: a range belongs to exactly one shard at a time. This is the point people most often get wrong. Copies of data exist *within* a shard, because every shard is a replica set; they do not exist *across* shards. Leftover documents on a donor shard after a migration are **orphans**, and shards filter them out of query results using their own copy of the ownership metadata. ## Where the map lives The config server replica set (CSRS) stores the routing table in the `config` database: `config.shards`, `config.databases`, `config.collections`, `config.chunks` (one document per range, with `min`, `max`, the owning `shard`, and a version stamp) and `config.tags` for zones. A `mongos` router caches this table in memory. When a router sends an operation to a shard using a stale version, the shard rejects it with a stale-config error; the router refreshes from the config servers and retries. That is why a migration produces a brief burst of metadata refreshes rather than wrong answers. ## What the balancer is and how it decides The balancer is a background task on the **config-server primary** (it moved there in MongoDB 3.4; before that it ran in `mongos`). It works in rounds and evaluates each sharded collection independently — one collection can be perfectly even while another is skewed. Starting in MongoDB 6.0 the balancer compares **data size per shard for that collection**, not the number of chunks. That matters because ranges are not uniform: one 128 MB range and one 2 KB range used to count the same, so a cluster could report an even chunk count while one shard carried most of the bytes. The documented trigger is a difference between the most- and least-loaded shard larger than three times the configured range size; below that the collection is considered balanced and nothing moves. When it decides to act, the balancer sends `moveRange` to the donor shard's primary. A shard participates in at most one migration at a time, so the number of concurrent migrations in an *n*-shard cluster is bounded by roughly *n*/2 disjoint donor/recipient pairs. ## Splitting and merging Before MongoDB 6.0, `mongos` tracked bytes written and triggered an auto-split once a chunk was estimated to exceed the configured chunk size. That auto-splitter was removed in 6.0: ranges are now split only when the balancer needs to carve off data to move, plus whatever an operator does explicitly with `sh.splitAt()` or `sh.splitFind()`. In the other direction, recent versions merge contiguous ranges owned by the same shard automatically, and `configureCollectionBalancing` with `defragmentCollection: true` runs that consolidation on demand. Fewer, larger ranges mean less routing metadata for every router and shard to cache. ## What you actually look at `sh.status()` prints, per sharded collection, the shards, their ranges and any zones. `sh.getBalancerState()` says whether the balancer is enabled; `sh.isBalancerRunning()` says whether a round is active right now; `db.adminCommand({balancerCollectionStatus: "db.coll"})` says whether the balancer thinks a specific collection still has work to do. Completed moves are logged in `config.changelog` as `moveChunk.start` / `moveChunk.commit` entries, which is the cheapest way to see how much migration traffic a cluster is generating. ## What the balancer does not fix The balancer equalizes *stored bytes*, not *traffic*. If every insert lands at the top of a monotonically increasing shard key, the newest range is always hot and moving it elsewhere just moves the hotspot. Distribution problems caused by shard-key design are not balancer problems.