Summary

Execution team has introduced a new option named ‘commitQuorum’ to ‘createIndexes’ command as part of PM-253 (Two phase commit for index build). ‘commitQuorum’ is very similar to writeConcern options which can accept an integer or a string - “majority”and custom write concern option. In addition to those values, the new ‘commitQuorum’ option will also accept “votingMembers” string value. A primary node that coordinates an index build can’t complete an index build until it has received votes from secondaries stating that they have each finished collection scanning and draining phase for that index build. The number of votes the primary has to wait before committing an index depends on the commitQuorum option’s value. The primary is also eligible to vote and it will vote for itself.

The main purpose of this new ‘commitQuorum’ option is to prevent slow secondaries replication from getting blocked on applying ‘commitIndexBuild’ oplog entry waiting for the index build completion on that secondary.

The current default value for the ‘commitQuorum’ option in 4.4 RC0 is “majority”, i.e., majority of voting data bearing nodes. Currently, some implementation issues with initial sync and abort index build logic have prevented us from making the default value for ‘commitQuorum’ as ‘votingMembers’, i.e., all voting data bearing nodes. For MongoDB 4.4 GA, the default value for ‘commitQuorum’ will be ‘votingMembers’ and we are working towards making the default value change (SERVER-46823).

For a quick reference, if a user wants to create an index ‘x_1’ on foo.bar collection with a commit quorum value as “votingMembers”, then the shell syntax will be:

>> db.runCommand(
{createIndexes: “bar”,
indexes: [{name: "x_1", key: {x: 1}}],
commitQuorum: "votingMembers"});

Say, if it’s a 3 node replica set (PSA), then the primary index build will wait for 2 votes (PS) to commit the index build.