-
Type: Improvement
-
Resolution: Won't Fix
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
Execution Team 2023-03-20, Execution Team 2023-04-03, Execution Team 2023-04-17, Execution Team 2023-05-01, Execution Team 2023-05-29, Execution Team 2023-06-12, Execution EMEA Team 2023-06-26
Explore avoiding stepdowns during the early phases of index build setup, until the build reaches kPostSetup.
Original description
An index build can register and get stuck trying to acquire a ticket to actually do the setup (and replicate startIndexBuild). So it is possible for the index build to be registered, when a stepdown happens, which does not kill the builders opCtx, and the build is still stuck after going into steady state replication as secondary. The new primary drops the collection, and on applying the drop in the secondary, we assert that there are no builds in progress... but there is one which is registered because the old primary has not yet advanced to a point where it checks if it is still primary.
Being blocked on ticket acquisition is not a necessity for this to manifest, as a sufficiently slow machine could theoretically suffer from the same issue.
- depends on
-
SERVER-70127 Default system operations to be killable by stepdown
- Closed
- is related to
-
SERVER-44250 startIndexBuild oplog write and thread pool scheduling are not serialized between concurrent threads on primaries
- Closed
-
SERVER-77025 Command application conflicting with index build should wait for its completion (partial revert of SERVER-61481)
- Closed
-
SERVER-75059 Explore improvements on index build concurrent state handling
- Closed
- related to
-
SERVER-78143 Complete TODO listed in SERVER-74953
- Closed