Hot shard diagnosis and shard key remediation
Parent: Independent shard scaling and per-shard tiering · Published reference · snapshot 2026-10-23 · skill mongodb-cohort-1d6ef7b4932c
↓ Facts as markdownall context files
Source-anchored research for Hot shard diagnosis and shard key remediation. Run status: COMPLETED.
These notes link each claim to its source. Some citations identify archived research reports that are no longer hosted on this site. A published reference means the content is available; it does not certify independent review or accuracy.Read the editorial policy and follow the sources before relying on a claim.
How it works
- analyzeShardKey reports key characteristics from sampled documents and read/write distribution from sampled queries; read/write results can be zero or omitted without query-analyzer samples, and representative results may require sampling across several days. MongoDB's Jira records an early 7.0-era bug that misreported monotonicity for compound hashed keys, fixed in 7.0.0-rc1 and 7.1.0-rc0, so validate results against per-shard observations and confirm the server release when investigating older deployments. (medium confidence) (verified as of 2026-10-23) [source]
- Balanced chunk counts or document volume do not establish balanced workload. A hot shard receives a disproportionate share of read or write traffic, which can happen when activity concentrates on particular shard-key ranges. (high confidence) [source]
Problems, failure modes and limitations
- Low cardinality and high-frequency key values can limit chunk creation or make chunks indivisible, while high cardinality alone does not guarantee even distribution. Refining a key with additional fields or resharding to a higher-cardinality key can address this structural skew. (high confidence) [source]
Comparisons and alternatives
- A hot shard is a workload skew rather than simply an uneven chunk map: monotonically increasing keys can route new writes to the same hot chunk, while reads of recent data can concentrate on the shard holding recent ranges; the hot shard can move after chunk splits. (high confidence) [source]
Facts and statements
- Diagnose a suspected hot shard with per-shard operation rates and latency, separated by operation type, and compare them with aggregate cluster metrics and chunk distribution. Netdata describes even chunk counts and healthy aggregate metrics masking a shard with disproportionate traffic; MongoDB's analyzeShardKey can add sampled key-range read/write distribution. (high confidence) [source]
- Choose remediation from cardinality, value frequency, monotonicity, and query patterns together. MongoDB recommends resharding an unsuitable monotonic key, and hashed sharding can distribute sequential values but loses ordered range access; frequent values and low cardinality remain separate skew risks. refineCollectionShardKey only appends suffix fields, so changing a defective existing prefix requires resharding to a different key (inference from the documented refine and reshard operations). (high confidence) [source]
- Diagnose suspected hot shards by comparing per-shard operation rates and latency with chunk distribution, then distinguish write skew on a monotonic key range from read skew on recently accessed data or other frequently targeted ranges. Check whether common queries include the shard key before treating the issue as a query-routing problem. (medium confidence) [source]
- MongoDB's analyzeShardKey evaluates a current or candidate shard key using sampled documents and queries. Its metrics cover key cardinality, frequency, monotonicity, and read/write distribution across key ranges. Query sampling must be configured before interpreting read/write distribution, and the key-characteristic metrics require a supporting index. (high confidence) [source]
- A monotonically increasing or decreasing range key routes new inserts to the chunk bounded by MaxKey or MinKey, making the shard that owns that range an insert bottleneck. Splitting can move the hot range between shards, but it does not remove the concentration of writes at the current range boundary. (high confidence) [source]
- Resharding with a non-monotonic key or using a hashed key can reduce insert concentration from a monotonic range key. Hashing is workload-dependent: it removes ordered locality, so range queries on the hashed key can become less efficient scatter-gather queries. Choose the replacement key to balance write distribution with common query targeting. (high confidence) [source]
Children
- No children recorded.