-
Type: Improvement
-
Resolution: Won't Do
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
Storage Execution
The way index build state is handled is very racy.
The way active index builds are managed. Active index builds are registered before the 'startIndexBuild' oplog entry is replicated, which leaves open the possibility of a node stepping down, and encountering oplog entry for a DDL operation which assumes no index builds are in-progress (e.g. a collection drop) while the index build is still registered. SERVER-74953 tries to mitigate the issue by making the builder thread interruptible until the oplog entry is replicated, but it won't make the problem disappear.
The reverse is also true, a committed index build de-registered and cleaned-up can race with step-up checks. And the way index builds are de-registered is all over the place. A search for "activeIndexBuilds.unregisterIndexBuild" turns up 10+ instances.
...
- is related to
-
SERVER-82967 Stepdown after calling ActiveIndexBuilds::registerIndexBuild() during index build setup doesn't unregister itself
- Closed
-
SERVER-75585 Explore simplifying the index build state machine
- Closed
- related to
-
SERVER-39968 improve filtering logic in IndexBuildsCoordinator during secondary oplog application
- Closed
-
SERVER-74953 Explore avoiding stepdowns during the early phases of index build setup
- Closed