-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: 4.3.3
-
Component/s: None
-
None
-
Fully Compatible
-
ALL
-
Execution Team 2020-01-13, Execution Team 2020-01-27, Execution Team 2019-12-30
-
43
Implicit collection creation bypasses the IndexBuildsCoordinator thread pool on the primary and replicates "startIndexBuild" oplog entries directly. The thread pool size is 10 on both primaries and secondaries, and is used to limit resource usage. Each additional index build will block until a thread resource is available.
This is problematic in the following scenario:
- Start, but do not complete 10 (or the current thread pool size) index builds on the primary.
- Using createIndexes, implicitly create a collection as of
SERVER-44405. This will replicate a "startIndexBuild" oplog entry, but will block on the secondary because all thread pool resources are in use. None of the in-progress index builds can commit because replication is now blocked.
This results in a deadlock, which stalls replication on the secondary
- is related to
-
SERVER-45718 Index builder can skip index building for a non-empty collections due to incorrect fast count value.
- Closed
-
SERVER-46603 disallow empty collection index build optimization on secondaries
- Closed
- related to
-
SERVER-45347 2-phase index build on empty collection(implicit collection creation) can skip rebuilding the index on rollback/startup recovery.
- Closed
-
SERVER-46668 createIndexes command does not honor wtimeout when replication is disabled on v4.5.0-24-gb801dec
- Closed
-
SERVER-38961 Remove override for causally consistent index builds once two-phase index builds are complete
- Closed