[SERVER-42281] IndexBuildsCoordinator fails to clean up index build when lock acquisition times out Created: 18/Jul/19  Updated: 29/Oct/23  Resolved: 22/Jul/19

Status: Closed
Project: Core Server
Component/s: Storage
Affects Version/s: None
Fix Version/s: 4.3.1

Type: Bug Priority: Major - P3
Reporter: Benety Goh Assignee: Benety Goh
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-39454 Move createIndexes command fully onto... Closed
Related
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Execution Team 2019-07-29
Participants:
Linked BF Score: 0

 Description   

If the IndexBuildsCoordinator fails to acquire the locks for the index build, it may leave the index build, with its corresponding BackgroundOperation, in an unfinished state. This can happen when the createIndexes is invoked with a short maxTimeMS duration.

The resulting inconsistent may affect subsequent metadata operations such as collections drops and renames that check BackgroundOperation::assertNoBgOpInProgForNs().

This is applies only when the IndexBuildsCoordinator is enabled for the createIndexes command.



 Comments   
Comment by Githook User [ 22/Jul/19 ]

Author:

{'name': 'Benety Goh', 'username': 'benety', 'email': 'benety@mongodb.com'}

Message: SERVER-42281 add concurrency test suite to alternate createIndexes builder
Branch: master
https://github.com/mongodb/mongo/commit/885fd466b41a4d4c3e1665be04838f5d6f14f897

Comment by Benety Goh [ 22/Jul/19 ]

Re-opening to extend test coverage in alternate createIndexes builder

Comment by Githook User [ 22/Jul/19 ]

Author:

{'name': 'Benety Goh', 'email': 'benety@mongodb.com', 'username': 'benety'}

Message: SERVER-42281 IndexBuildsCoordinator::_runIndexBuildInner() cleans up index build if lock acquisition fails
Branch: master
https://github.com/mongodb/mongo/commit/121972781acf4a5db3cc26e6151044954d612574

Generated at Thu Feb 08 05:00:04 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.