# MongoDB commit quorum and two-phase index builds > Source-anchored research for MongoDB commit quorum and two-phase index builds. Run status: COMPLETED. Parent: [Resumable index builds](https://llms-explorer.com/tree/resumable-index-builds/) · 5 facets · 16 facts · page: https://llms-explorer.com/tree/mongodb-commit-quorum-and-two-phase-index-builds/ ## Definitions - Commit quorum is the readiness threshold that the primary must satisfy before committing a replicated index build. Its default, votingMembers, requires all data-bearing voting replica-set members, including the primary; it is not merely a majority threshold. (high confidence) — [source](https://www.mongodb.com/docs/manual/reference/command/createIndexes.md) ## How it works - Commit quorum alone does not guarantee that secondary indexes are usable when createIndexes returns. MongoDB 8.0 documentation distinguishes pre-commit readiness votes from post-commit write concern, which waits for replication of the index-build oplog entry; earlier releases described write concern as waiting for members to finish the index build. (high confidence) (verified as of 2026-10-30) — [source](https://www.mongodb.com/docs/manual/reference/command/createIndexes.md) - SERVER-46668 records a createIndexes test hanging with writeConcern {wtimeout:1,w:3} when secondary replication was disabled on a MongoDB 4.5 development build, and was resolved Works as Designed. This historical reproduction is evidence against assuming wtimeout bounds every phase of an index build; it is not a current-version reproduction. (low confidence) — [source](https://jira.mongodb.org/browse/SERVER-46668) ## Problems, failure modes and limitations - setIndexCommitQuorum has no effect on a build started with commitQuorum: 0. Replica-set members configured with buildIndexes: false cannot participate in a commit quorum. (low confidence) — [source](https://www.mongodb.com/docs/manual/reference/command/setIndexCommitQuorum.md) - A build started with commitQuorum: 0 cannot have its quorum changed through setIndexCommitQuorum; the command has no effect on such a build. (low confidence) — [source](https://www.mongodb.com/docs/manual/reference/command/setIndexCommitQuorum.md) - Members with buildIndexes:false cannot be included in a commit quorum. If a voting member has that setting, the command documentation says the default votingMembers quorum cannot be used; enable index building on the relevant members or choose another quorum. (high confidence) (verified as of 2026-10-30) — [source](https://www.mongodb.com/docs/manual/reference/command/createIndexes.md) ## Comparisons and alternatives - Quorum readiness does not override index constraints: after reaching quorum, the primary checks remaining constraints and can still abort rather than commit. (low confidence) — [source](https://github.com/mongodb/mongo/blob/master/src/mongo/db/index_builds/README.md) - If a required voting data-bearing member is unavailable, an index build using votingMembers can wait despite the primary finishing its local work. Percona's three-node experiment completed with majority while one secondary was down, demonstrating the availability tradeoff rather than a universal recommendation. (medium confidence) — [source](https://www.percona.com/blog/commitquorum-in-index-creation-from-percona-server-for-mongodb-4-4/) - Changing commit quorum changes the commitment threshold, rather than selecting the only members that build the index. A secondary outside the satisfied quorum can still need to finish its local index build, blocking further oplog application when it processes commitIndexBuild. (high confidence) — [source](https://www.mongodb.com/docs/manual/reference/command/setIndexCommitQuorum.md) - Percona's June 29, 2023 experiment used majority quorum to complete a new index build with one of three data-bearing members unavailable. This demonstrates a particular topology and release, rather than a guarantee that majority can satisfy every degraded replica-set configuration. (low confidence) — [source](https://www.percona.com/blog/commitquorum-in-index-creation-from-percona-server-for-mongodb-4-4/) ## Facts and statements - A member votes after scanning the collection and completing the first drain of side writes; voteCommitIndexBuild persists the vote in replicated config.system.indexBuilds. Members continue applying side writes while awaiting a commit decision. (low confidence) — [source](https://github.com/mongodb/mongo/blob/master/src/mongo/db/index_builds/README.md) - The documented two-phase checkpoint-recovery path requires votingMembers: after an eligible clean shutdown or SIGTERM, progress can be saved and resumed. The server design README additionally scopes general resumability to a voting replica-set member with majority read concern enabled. A lower quorum must not be assumed to preserve these recovery guarantees. (high confidence) (verified as of 2026-10-30) — [source](https://www.mongodb.com/docs/manual/reference/command/createIndexes.md) - createIndexes accepts a commitQuorum option. setIndexCommitQuorum changes the threshold for an eligible running build, and indexNames must include every index associated with that single createIndexes operation. MyDBOps illustrates changing a two-index build from votingMembers to majority. (high confidence) — [source](https://www.mongodb.com/docs/manual/reference/command/createIndexes.md) - SERVER-127743 describes a retained commit vote after a node dies and restarts a two-phase build from scratch, especially after unclean shutdown. SERVER-124042 reports quorum satisfaction during a restart race while nodes were still rebuilding. These reports scope readiness guarantees; they do not establish a general index-corruption result or identify affected releases. (medium confidence) (verified as of 2026-10-26) — [source](https://jira.mongodb.org/browse/SERVER-127743) - With votingMembers, an unreachable data-bearing voting member can leave an index build waiting for quorum. Percona independently demonstrated this in PSMDB 4.4.22-21: a three-data-bearing-member replica set waited while one secondary was unavailable and completed after that member returned. (high confidence) — [source](https://www.mongodb.com/docs/v8.0/core/index-creation/) - For MongoDB 8.0's documented two-phase recovery path, an unclean crash restarts the build from the beginning regardless of quorum. The documentation also limits checkpoint resumption to once per build; a further restart during that build starts it from the beginning. (low confidence) (verified as of 2026-10-30) — [source](https://www.mongodb.com/docs/v8.0/core/index-creation/)