Index build commit quorum and hung builds
Parent: Index build resource limits (maxNumActiveUserIndexBuilds, disk space) · Published reference · snapshot 2026-10-31
↓ Facts as markdownall context files
Source-anchored research for Index build commit quorum and hung builds. 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
- For simultaneous replicated builds, votingMembers is the default commit quorum and requires all data-bearing voting members, including the primary, to become ready before commit. (high confidence) [source]
How it works
- SERVER-71768 reports Atlas builds stalling when a secondary already has the index and skips voting, with interrupted rolling builds suspected. Its documented workaround is adjusting the quorum. (medium confidence) [source]
Problems, failure modes and limitations
- setIndexCommitQuorum has no effect on a build started with commitQuorum: 0. Members configured with buildIndexes: false cannot participate in a commit quorum. (low confidence) [source]
- SERVER-56976 records a historical bug where changing quorum failed to wake a build already waiting for votes. The issue lists fixes in 4.4.7, 5.0.0-rc0, and 5.1.0-rc0; this does not establish failure in current versions. (low confidence) [source]
- setIndexCommitQuorum cannot alter a build started with commitQuorum: 0. (low confidence) [source]
- A member configured with buildIndexes: false cannot participate in commit quorum; a voting member with this setting prevents use of votingMembers. (high confidence) [source]
- Starting in MongoDB 7.1, low disk space can trigger index-build abortion, but a member that has already voted to commit cannot retract its vote to request abortion. Do not assume the disk-space threshold always stops a waiting build. (high confidence) (verified as of 2026-10-14) [source]
Comparisons and alternatives
- Percona reproduced a default-quorum build waiting with one of three data-bearing members down; currentOp showed "Index Build: draining writes received during build". This message can therefore reflect quorum waiting rather than ongoing application writes. (medium confidence) [source]
Facts and statements
- The default commitQuorum is "votingMembers": all data-bearing voting replica-set members. An unreachable required member can leave an index build hanging until it returns. (medium confidence) [source]
- Members vote after scanning the collection and the first side-write drain. While awaiting the commit decision, the build continues applying side writes; finishing the scan is not equivalent to completing the build. (high confidence) [source]
- setIndexCommitQuorum changes an in-progress build’s quorum. indexNames must include the entire group of indexes created by its single createIndexes operation. (high confidence) [source]
- Lowering commit quorum can let the primary commit sooner, but an unfinished secondary receiving commitIndexBuild can block further oplog application until its local build finishes. (high confidence) [source]
- Commit quorum controls readiness before primary commit. Starting in MongoDB 8.0, write concern waits for replication of the index-build oplog entry; earlier releases waited for the specified nodes to finish building the index. (high confidence) (verified as of 2026-10-14) [source]
- SERVER-87929 reports that changing a member's votes to zero did not update the quorum of an already-running build until primary stepdown or explicit quorum adjustment. The issue was resolved Won't Do in April 2024; treat this as a documented case, not a universal current-version guarantee. (low confidence) [source]
- In a 2020 firsthand report, a four-document collection hung with the draining-writes message despite no application writes. The author reported a node self-communication problem and a keyfile-related resolution after consulting MongoDB; this is historical case evidence, not a universal workaround. (low confidence) [source]
- SERVER-115085 describes an initial-sync member delaying index-build quorum until collection cloning finishes and index-build oplog entries are applied. The proposed automatic adjustment was closed Works as Designed, so the proposal is not evidence that automatic quorum reduction shipped. (low confidence) [source]
- The manual directs operators to dropIndexes or its shell helpers to stop in-progress replicated builds, and warns against using killOp for replica sets or sharded clusters. (low confidence) [source]
- An unreachable data-bearing voter can hold a default-quorum index build indefinitely; Percona reproduced a build completing after the missing third member returned. (high confidence) [source]
- Inference: quorum waiting can prolong the lifetime of active builds, so increasing maxNumActiveUserIndexBuilds does not repair an unsatisfied quorum and can admit additional resource-consuming work. (medium confidence) [source]
Children
- Commit quorum versus write concern in MongoDB 8.0 (frontier)
- Diagnosing voteCommitIndexBuild communication failures (frontier)
- Commit-ready votes and disk-space abort eligibility (frontier)
Frontier under this node: Commit quorum versus write concern in MongoDB 8.0, Commit-ready votes and disk-space abort eligibility, Diagnosing voteCommitIndexBuild communication failures