dropIndexes locking and rollback by rebuild
Parent: Unused index detection with $indexStats · Published reference · snapshot 2026-10-23 · skill mongodb-cohort-b17c7aa5e0c9
↓ Facts as markdownall context files
Source-anchored research for dropIndexes locking and rollback by rebuild. 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.
Definitions
- Recreating a dropped index is a new index build, not an instant rollback. MongoDB documents that builds on populated collections briefly hold an exclusive collection lock at the beginning and end, and that builds during write-heavy workloads can reduce write performance and take longer; plan the rebuild for representative load and monitor it. (high confidence) [source]
Problems, failure modes and limitations
- dropIndexes kills queries that use the index being removed, including queries still considering it during planning. After the drop, the planner cannot use that index; reads can regress if the remaining plan is slower, so validate critical query shapes and representative traffic before and after removal. (medium confidence) [source]
- Rebuilding a dropped unique index can fail if conflicting values were written while the unique constraint was absent. MongoDB checks existing and concurrently written documents for unique-constraint violations during the build and terminates the build if violations remain, so duplicate data must be resolved before the unique index can be restored. (high confidence) (verified as of 2026-10-23) [source]
Comparisons and alternatives
- Hiding an index is the reversible test: MongoDB keeps maintaining a hidden index, excludes it from planning, and makes it immediately available again when unhidden. After the index is actually dropped, recovery requires recreating the equivalent index with createIndex rather than unhiding it. (high confidence) [source]
- A rebuild after a drop is a new createIndex operation on the current collection data, not an immediate reversal of dropIndexes. MongoDB documents that index builds on populated collections hold an exclusive collection lock briefly at the start and end, while yielding to reads and writes during the rest of the build; this build-lock behavior differs from dropIndexes holding its lock for the full removal operation. (high confidence) (verified as of 2026-10-23) [source]
- Dropping an unused index can reduce write and storage overhead, but removing an index used by read queries can change plans and cause slower scans. Netdata advises dropping during lower traffic and monitoring lock waits and query plans afterward; Percona describes the read benefit and write and storage costs of indexes, supporting workload-specific validation rather than treating every unused-index result as safe for removal. (medium confidence) [source]
Facts and statements
- The MongoDB 7.0 and 8.0 command manuals describe the same dropIndexes locking behavior: it holds an exclusive lock on the target collection for the command's duration, and subsequent operations on that collection wait for release. The manuals do not describe this as an 8.0 change or as a database-wide lock; an independent operations guide dates the move from database to collection lock scope to MongoDB 4.2. (high confidence) (verified as of 2026-10-23) [source]
- Before dropping a production index to test its query impact, MongoDB recommends hiding it. Hidden indexes remain maintained and can be unhidden if performance degrades, restoring planner availability without a rebuild; they also continue to use disk and memory and receive write updates, so hiding does not remove index-maintenance overhead. (high confidence) [source]
Children
- No children recorded.