MongoDB uses B-Tree internally. We will understand about Terminating In-progress index builds, and the index build process, commit quorum, and dropping an index in this blog. I have added flow charts to make the information interactive. let’s start!

1. Terminate In-Progress Index Builds
   1. Before 4.4
   2. From 4.4
   3. Abort In-Progress Index Builds
   4. Commit Quorum
   5. Requires featureCompatibilityVersion 4.4+
   6. Index Build Process
2. Set Index Commit Quorum
   1. setIndexCommitQuorum
   2. Resource locking

Terminate In-Progress Index Builds

Before 4.4

We can terminate the in-progress index. Look into the below steps to kill the index.

• To kill in-progress index build, use db.killOp(opid) command before 4.4.
• Don’t terminate the index build process on secondary nodes in the replica sets.
• Shouldn’t terminate a replicated index built on secondary members of a replica set. If the index needs to drop once the index is replicated to secondary, use the drop command. Use db.collection.dropIndex() on the primary. The secondary nodes will replicate the drop operation and drop the indexes after the index build completes.

From 4.4

• You can use the dropIndex command to terminate an in-progress index build.
• db.collection.dropIndex()
• From 4.4 don’t use the db.killOp() to terminate the in-progress index on replica or sharded clusters.

Abort In-Progress Index Builds

• If you use the drop index command on the in-progress index. drop indexes attempt to abort the in-progress build. If it is a replica set run the dropIndex command in the primary.
• Primary aborts the index builds and creates the associated oplog entry with the name “abortIndexBuild”.secondaries will replicate the oplog entry and abort the index-build process.
• If at a time multiple index builds are in-progress and need to drop one index we need to wait until the index builds are complete and specify that index to drop indexes.

Commit Quorum

The minimum number of data-bearing replica set members (i.e. commit quorum), including the primary, must report a successful index build before the primary marks the indexes as ready.

Starting with MongoDB 4.4,

• Index builds on a replica set or sharded cluster built simultaneously across all data-bearing replica set members.
• The primary requires the majority of the votes to complete the build before marking the index as ready for use.
• A “voting” member is any replica set member, where members[n].votes are greater than 0.

Members[n].votes

• The number of votes a server will cast in a replica set election. The number of votes each member has is either 1 or 0, and arbiters always have exactly 1 vote.
• A priority 0 member is a member that cannot become primary and cannot trigger elections. But the priority 0 members must also be a voting members (i.e. members[n].votes is greater than 0)

Starting with MongoDB 4.4, index builds on a replica set or sharded cluster build simultaneously across all data-bearing replica set members.

Requires featureCompatibilityVersion 4.4+

Each mongod in the replica set or sharded cluster must have featureCompatibilityVersion set to at least 4.4 to start index builds simultaneously across replica set members.

MongoDB 4.4 running featureCompatibilityVersion: “4.2” builds indexes on the primary before replicating the index build to secondaries.

Index Build Process

Set Index Commit Quorum

setIndexCommitQuorum

Introduced in version 4.4.

The setIndexCommitQuorum changes the minimum number of data-bearing voting members.

 
db.runCommand(
{
setIndexCommitQuorum: ,
indexNames: [  ],
commitQuorum:  | ,
comment: 
}
)
	

The command takes the following parameters

setIndexCommitQuorum: It is a string type, and it holds the name of the collection index being built.

indexNames: An array of in-progress index builds to modify. Each element of the array must be the name of the index.

commitQuorum: The minimum number of data-bearing voting replica set members, including the primary, that must report a successful index build before the primary marks the indexes as ready

Here, commitQuorum supports a few values.

• votingMembers – all data-bearing voting replica set members. This default one.
• majority – a simple majority of data-bearing voting replica set members.
• <int> – a specific number of data-bearing voting replica set members. Specify an integer greater than 0.

Comment: Optional. A user-provided comment to attach to this command.

Example: The following operation starts an index build of two indexes for people collection in example’s database.

Let us consider we are having two in-progress indexes.

 
db.getSiblingDB("examples").people.createIndexes(
[
{ "name" : 1 },
{ "Address" : 1 }
]
)
	

We are changing the commit quorum value from default to the majority.

By default, index builds use “votingMembers” commit quorum, or all data-bearing voting replica set members. The following operation modifies the index build commit quorum to “majority” or a simple majority of data-bearing voting members.

 
db.getSiblingDB("examples").runCommand(
{
"setIndexCommitQuorum" : "people",
"indexNames" : ["name_1","Address_1"],
"commitQuorum" : "majority"
}
)
	

The indexNames field specifies the names of the indexes. Since the indexes were created without an explicit name, MongoDB generated an index name by concatenating the names of the indexed fields and the sort order.

The indexes specified to indexNames must be the entire set of in-progress builds associated to a given index builder, i.e. the createIndexes() operation.

Drop Index

The dropIndexes command can also be used to drop an existing index and an in-progress index from 4.4.

 
db.collection.dropIndex()
	

Resource locking

• Earlier to MongoDB 4.2 version when we use db.coll.dropIndex() it obtains an exclusive lock on the parent database and blocks all operations on the database and collections in the database must wait until the index is dropped successfully.
• From MongoDB 4.2 version, when we use db.coll.dropIndex() obtains an exclusive lock on the specified collection and all operations must wait until the index is dropped.
• Prior to MongoDB 4.2, dropping an index on a collection would kill all open queries on the collection.

I sincerely hope that this blog will help the readers to become more familiar with the index build process and terminating in-progress indexes. In the upcoming posts, let’s get more in-depth. Happy Learning!!!

Unlock Peak MongoDB Performance! Mydbops offers a full suite of MongoDB database management services, including expert guidance on index management. Contact us today and let our team help you optimize your MongoDB deployments!

{{cta}}