Commit quorum and the vote-to-commit point of no return
Parent: Index build resource limits (maxNumActiveUserIndexBuilds, disk space) · Published reference · snapshot 2026-10-31
↓ Facts as markdownall context files
Source-anchored research for Commit quorum and the vote-to-commit point of no return. 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 replica-set index builds, commitQuorum is a readiness threshold including the primary; the default votingMembers waits for all data-bearing voting members. Changing the threshold does not restrict index building to the members counted in the quorum. (medium confidence) [source]
How it works
- A default-quorum build can wait for an unreachable data-bearing voting member. Percona independently demonstrates a three-member deployment waiting until its missing member returns; Qubership documents stuck final-phase builds alongside a replica in RECOVERING. These operational observations support checking member health when a build appears stuck. (medium confidence) [source]
Problems, failure modes and limitations
- In the MongoDB 7.1-and-later two-phase protocol, a secondary that has not voted to commit can send voteAbortIndexBuild to request a coordinated abort through the primary. Once that secondary votes to commit, it cannot retract its vote; if a later local error requires abort while it awaits the decision, it is forced to crash. (high confidence) (verified as of 2026-10-30) [source]
- The point of no return is local vote withdrawal, not irrevocable global success. The primary can still fail final constraint checks and replicate abortIndexBuild; even a secondary that already voted to commit gracefully follows a replicated abort. (high confidence) [source]
- Reducing commit quorum trades earlier primary commit against lag risk: a secondary outside the quorum can block oplog application when it receives commitIndexBuild until its own build can commit. Quorum alone therefore does not certify immediate index usability on every secondary. (high confidence) [source]
Facts and statements
- For simultaneous replica-set builds, commitQuorum defaults to votingMembers: all data-bearing voting members, including the primary. An unreachable required voter can leave the build waiting indefinitely. (high confidence) (verified as of 2026-10-30) [source]
- A member sends voteCommitIndexBuild after scanning collection data and draining side writes once; the vote is persisted in config.system.indexBuilds. Members continue processing side writes while awaiting the primary decision, so a readiness vote is not the final commit. (high confidence) [source]
- setIndexCommitQuorum changes the threshold for an in-progress simultaneous build. Its indexNames must identify the entire group created by the same createIndexes operation, and it has no effect on builds started with commitQuorum: 0. (low confidence) (verified as of 2026-10-30) [source]
- Starting in MongoDB 8.0, commit quorum gates primary commit, while write concern gates successful command return on replication of the index-build oplog entry. Earlier releases used write concern to wait for the specified nodes to finish the index build; older statements equating acknowledgement with secondary index readiness require this version qualification. (high confidence) (verified as of 2026-10-30) [source]
- Percona demonstrated a three-data-bearing-node build completing with commitQuorum: majority while one secondary was down; its default votingMembers example waited for the unavailable member. (low confidence) [source]
- SERVER-101487 records cases where a secondary failed to restart an index build, leaving commit quorum waiting for a build that would not finish. The issue is marked Works as Designed, with no fix version listed. (low confidence) (verified as of 2025-07-24) [source]
- The current development README also describes primary-driven index builds, where the primary replicates internal index writes and commit quorum does not apply. Claims about readiness voting here are scoped to simultaneous two-phase builds; the README alone does not establish a released-version availability boundary for primary-driven builds. (low confidence) (verified as of 2026-10-30) [source]
Children
- No children recorded.