Shard key index constraints when dropping or hiding indexes
Parent: Hidden indexes and safe index removal · Published reference · snapshot 2026-10-23 · skill mongodb-cohort-ab6ca72e8dcd
↓ Facts as markdownall context files
Source-anchored research for Shard key index constraints when dropping or hiding indexes. 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
- A sharded collection needs an index whose key pattern starts with the shard key; a compound index qualifies when the shard key is its prefix. For shard-key refinement, a supporting index for the new key must exist before the refinement command runs. (high confidence) [source]
- The current MongoDB manual lists MongoDB 5.0.22, 6.0.12, and 7.0.3 as the first releases that support dropping a hashed shard-key index. It recommends dropping the hashed index only when a supporting non-hashed shard-key index exists. Without that index, shard-key queries perform a collection scan. (high confidence) (verified as of 2026-10-20) [source]
- When the existing shard-key index is unique, MongoDB requires the new supporting shard-key index to be unique too; create the replacement unique index and drop the old shard-key index before running refineCollectionShardKey. Percona's refinement walkthrough also puts supporting-index creation before the refinement command. (high confidence) [source]
- MongoDB Jira marks the hide-index guard bug fixed in 6.0.4, 6.1.1, and 6.2.0-rc0; older affected deployments could hide a shard-key index even when dropping it was prohibited. (medium confidence) (verified as of 2022-11-11) [source]
- A sharded collection needs an index that supports its shard key; the index can match the key exactly or be compound with the full shard key as a prefix. For a ranged shard key, MongoDB blocks hiding or dropping the only non-hidden compatible index. The manual says `dropIndexes("*")` preserves the `_id` index and last shard-key-compatible index when one exists. In the pinned MongoDB `master` implementation checked on 2026-10-22, wildcard drops retain compatible indexes for non-hashed shard keys but can drop hashed-compatible indexes. (high confidence) (verified as of 2026-10-22) [source]
- When refining a shard key, MongoDB requires an existing index whose prefix matches the proposed new shard key, and the new key must retain the old key as its prefix by adding fields only as suffixes. Percona's procedure likewise creates the supporting index before running the refine command. (high confidence) (verified as of 2026-10-20) [source]
Facts and statements
- MongoDB normally rejects dropping or hiding the only non-hidden index that supports a shard key. MongoDB's SERVER-68769 issue records that an earlier bug allowed hiding a shard-key index that could not be dropped. (high confidence) [source]
- Hiding an index removes it from query planning but keeps it maintained on writes; a hidden unique index continues to enforce uniqueness. Hiding therefore tests query-planner impact without removing index constraints or maintenance cost. (high confidence) [source]
- Before dropping a hashed shard-key index, MongoDB's procedure stops the balancer and verifies that each shard has zero orphaned documents. After the drop, range deletion does not clean remaining orphans, and the collection is excluded from future balancing rounds until the hashed index is recreated. (high confidence) (verified as of 2026-10-20) [source]
- The hashed-index exception for dropping does not establish an exception for hiding the last supporting index: the current manual still prohibits hiding the only non-hidden shard-key index, and MongoDB Jira's SERVER-78995 request to permit hiding the last compatible hashed index is marked Duplicate. (medium confidence) [source]
- Hiding removes an index from query-planner consideration, but MongoDB continues maintaining it on writes and it continues using disk and memory. Hiding is therefore a reversible test of query-planner impact; it does not test the write or storage savings of dropping the index. (high confidence) [source]
- MongoDB's manual says a hashed shard-key index can be dropped starting in versions 5.0.22, 6.0.12, and 7.0.3. It recommends retaining a supporting non-hashed shard-key index to avoid collection scans for shard-key filters. Dropping the hashed index disables future balancing for the collection, and the range deleter does not clean remaining orphans, so the procedure requires confirming that no orphaned documents remain. (medium confidence) (verified as of 2026-10-20) [source]
- In MongoDB `master` as checked on 2026-10-22, the hide and drop guards call `isLastNonHiddenRangedShardKeyIndex`, so they apply to the last compatible ranged index. MongoDB issue SERVER-78995 records that hiding the last hashed-compatible index should be allowed after the hashed-index drop exception. The public manual does not state a released-version boundary for hiding that hashed index. (medium confidence) (verified as of 2026-10-22) [source]
Children
- Hashed shard-key index drop operational procedure (frontier)
- Unique index requirements when refining a shard key (frontier)
Frontier under this node: Hashed shard-key index drop operational procedure, Unique index requirements when refining a shard key