VisuaLeaf
Download Free
Try Free
Documentation

Sharding Activity

Sharding Activity

The Sharding Activity view is where you manage sharded MongoDB clusters end-to-end: mongos routers, the config-server replica set, and the underlying shard replica sets. From one page you can enable sharding on a database, shard a collection, inspect chunk distribution, watch the balancer move data around, and read moveChunk history.

Prerequisites

The Sharding Activity view requires a connection that points to a mongos router. Sharding cannot be administered from a shard's replica set directly. Add a mongos connection in the Connection Manager before opening this view.

Topology View

The topology view lays out the cluster as three tiers:

  1. mongos routers: the query routers your applications connect to.
  2. Config replica set: stores cluster metadata (chunk map, shard list, zone rules).
  3. Shards: replica sets that hold the actual data.

Each node is drawn as a card with health chips (see Replica Set Fleet for chip colors). Lines connect routers to config servers and config servers to shards, so partitioning problems are visible at a glance. Click any shard to open its replica-set monitor.

Enable Sharding on a Database

Before a database's collections can be sharded, sharding must be enabled at the database level.

  1. Click Enable sharding in the topology toolbar.
  2. Choose the target database from the dropdown.
  3. Optionally choose a primary shard — where non-sharded collections in this database will live.
  4. Confirm. VisuaLeaf runs sh.enableSharding("<db>") and refreshes the topology.

Shard a Collection

Sharding a collection distributes its documents across shards using a shard key. VisuaLeaf's Shard collection dialog walks you through the choices step by step.

Hashed vs Ranged Shard Keys

Strategy When to use Trade-offs
Hashed Even write distribution across shards; keys with monotonic values (like ObjectId or timestamps) Range queries on the shard key must scatter-gather across shards
Ranged Range queries on the shard key are common; data has natural locality (e.g. tenantId) Monotonic keys create a single "hot" shard; needs careful key design
Compound Ranged Combine a locality field (tenantId) with a distributing field (_id) Most flexible but the shard key becomes immutable — plan carefully

The dialog previews the resulting shardCollection command before executing it, and refuses to proceed if the required supporting index does not exist yet (offering to create it for you).

Zone / Tag Ranges

Zones (formerly called tags) pin ranges of the shard key to specific shards. Common uses:

  • Data residency — keep EU tenants on EU-region shards.
  • Tiered storage — put hot data on SSD shards, archived data on HDD shards.
  • Read locality — keep customer data close to their geographic region.

The Zones tab lists every zone, the shards tagged with it, and every zone-range currently mapped. You can add zones, tag shards, and add or drop ranges directly from the UI — VisuaLeaf translates each action into the equivalent sh.addShardTag, sh.updateZoneKeyRange, or sh.removeRangeFromZone command.

Chunk Distribution Browser

The chunk browser answers "how is my data actually distributed right now?"

  • Per-shard chunk counts with a bar chart of the distribution.
  • Chunk list with min, max, shard, lastmod, and estimated size.
  • Filters by database, collection, or shard.
  • Jumbo flag highlighted in red so you can see problems immediately.

Interpreting Jumbo Chunk Warnings

A chunk is marked jumbo when it exceeds the configured chunk size (default 128 MB) and cannot be split because every document inside has the same shard-key value. Jumbo chunks are the classic sign of a poorly-chosen shard key with too little cardinality. Options:

  • Add cardinality: switch to a compound shard key that includes a distributing field.
  • Refine the shard key (MongoDB 5.0+): use refineCollectionShardKey to append a suffix field.
  • Reshard the collection (MongoDB 5.0+): if the wrong key was chosen up front, resharding may be unavoidable.

VisuaLeaf will not attempt to auto-split jumbo chunks — the safe fix is at the shard-key level, not the chunk level.

Balancer Status

The balancer moves chunks between shards to keep the distribution even. The status panel shows:

  • Whether the balancer is currently running, stopped, or disabled.
  • Any active balancing window (e.g. off-hours only).
  • Whether a moveChunk is in flight right now, and for which collection.
  • A stop / start toggle guarded by a confirmation dialog.

moveChunk History

The moveChunk tab reads config.changelog and presents the history of chunk migrations: source shard, destination shard, key range, duration, and whether the migration succeeded or aborted. Sorting by duration surfaces slow migrations that may point to network or WT-cache issues; filtering by collection shows which collections the balancer is spending its time on.

Pro Tips

  1. Design the shard key before enabling sharding: the shard key is (practically) immutable. Model the workload first, shard second.
  2. Avoid low-cardinality keys: boolean or enum-like keys almost always produce jumbo chunks.
  3. Watch balancer during business hours: restrict the balancer window if migrations affect read latency.
  4. Combine with Fleet: a single unhealthy shard replica set will stall the balancer.

Ready to try VisuaLeaf?

Download and start managing your MongoDB databases with ease.

Download Free Trial