[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: |
|
||||||||
| Participants: | |||||||||
| Days since reply: | 3 years, 48 weeks, 5 days ago | ||||||||
| Epic Link: | DOCS: 4.4 Server Release Work | ||||||||
| Story Points: | 1 | ||||||||
| Description |
DescriptionDownstream 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
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 changesImpact to Other DocsMVP (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: |
| 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 |
| 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 > 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.
|