[DOCS-13420] Investigate changes in SERVER-37726: Make dropIndexes abort in-progress index builds Created: 18/Feb/20  Updated: 13/Nov/23  Resolved: 06/Mar/20

Status: Closed
Project: Documentation
Component/s: manual, Server
Affects Version/s: None
Fix Version/s: 4.3.4, Server_Docs_20231030, Server_Docs_20231106, Server_Docs_20231105, Server_Docs_20231113

Type: Task Priority: Major - P3
Reporter: Backlog - Core Eng Program Management Team Assignee: Ravind Kumar (Inactive)
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Documented
documents SERVER-37726 Make dropIndexes abort in-progress in... Closed
Participants:
Days since reply: 3 years, 48 weeks, 5 days ago
Epic Link: DOCS: 4.4 Server Release Work
Story Points: 1

 Description   

Description

Downstream Change Summary

The "dropIndexes" command can now be used to abort in-progress index builds being built in the background. As we can only abort at the builder level granularity, the user must specify all the indexes being built by a single index builder to abort it successfully.

This command still retains the previous behaviour of returning "BackgroundOperationInProgressForNamespace" when trying to drop a ready index while there are index builds still in-progress.

Description of Linked Ticket

dropIndexes should abort in-progress index builds. This should be done after SERVER-37763 makes it possible to abort an index build.

SERVER-37727 will enhance dropIndexes to receive an array of indexes as arguments. This task will only abort in-progress index builds if the user specifies all of the indexes that a single builder is building together. A createIndexes command can start multiple indexes building together on one builder and we currently only have the granularity to abort all or none of the indexes on a builder.

Lastly, dropIndexes will not write a dropIndexes oplog entry if aborting in-progress builds. Aborting the index will produce an abortIndexBuilds oplog entry, which suffices. This allows rollback via refetch to know that an index was fully built prior to a dropIndexes oplog entry.

Scope of changes

Impact to Other Docs

MVP (Work and Date)

Resources (Scope or Design Docs, Invision, etc.)



 Comments   
Comment by Githook User [ 06/Mar/20 ]

Author:

{'name': 'Ravind Kumar', 'username': 'rkumar-mongo', 'email': 'ravind.kumar@mongodb.com'}

Message: DOCS-13420: dropIndexes attempts to abort in-progress index builds before dropping index
Branch: master
https://github.com/mongodb/docs/commit/ee6e259a32449b984e9c96e31b2db8d671627d8e

Comment by Gregory Wlodarek [ 04/Mar/20 ]

Hi ravind.kumar

Correct, when index builds are ready on secondaries, they wait for the commit or abort oplog entry from the primary before proceeding. Whichever oplog entry is first in line on the secondary is the deciding factor for the index build on the secondary.

The primary does not immediately kill secondary index builds, it just creates the abortIndexBuild oplog entry which the secondaries get and eventually abort their index build from that.

The important takeaway here is to remember is that the index build will not finish on the secondaries until the commit or abort oplog entry is received for that index build from the primary.

If the index that was dropped on the primary was a ready index, then we simply send the dropIndexes oplog entry and maintain the old behaviour of dropping indexes.

 

FYI, there is also DOCS-13462 for dropDatabase . All of these commands behave the same way in terms of aborting in-progress index builds.

Comment by Ravind Kumar (Inactive) [ 02/Mar/20 ]

gregory.wlodarek quick question:

 

> Lastly, dropIndexes will not write a dropIndexes oplog entry if aborting in-progress builds. Aborting the index will produce an abortIndexBuilds oplog entry, which suffices. This allows rollback via refetch to know that an index was fully built prior to a dropIndexes oplog entry.

 

There's similar work on DOCS-13430 w.r.t. drop() on an ongoing index build where we note that it will not stop an in-progress index build on a secondary. the linked SERVER-46122 states:

> Secondaries should not abort in-progress index builds but instead wait for the abortIndexBuilds oplog entry.

Is this to say that the secondaries will only kill the ongoing index build when it reaches the abortIndexBuilds entry? i.e. drop() / dropIndexes() itself does not immediately kill secondary index builds. However, if the index builds are still in progress and the secondary hits that entry in the oplog, then the index build gets killed. If the indexes are already built, i'm assuming we drop the indexes (i.e. abortIndexBuilds implies dropIndexes)

cc jeffrey.allen@mongodb.com as this might have some impact on your ongoing work.

 

Generated at Thu Feb 08 08:07:44 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.