-
Type: Task
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Replication
-
Fully Compatible
-
Sharding 2020-12-14, Sharding 2020-12-28, Sharding 2021-01-11, Sharding 2021-01-25
We decided at the 6 week review that the donor should bound how long it blocks operations.
This is useful in general to limit the impact of a tenant migration on a user workload, but in particular is useful in case the donor starts blocking very soon after writing a commitIndexBuild oplog entry. This is because the recipient will not start building the index until seeing commitIndexBuild in the oplog; will not report that it has majority-committed the commitIndexBuild oplog entry until finishing building the index; and building the index can take a long time (hours).
suganthi.mani or matthew.russotto , could you confirm that this is the plan for how the recipient will handle two-phase index builds?
evin.roesle, could you propose a default upper bound for how long the donor should block operations? The upper bound should be settable via a server parameter.
- is depended on by
-
SERVER-53571 Determine the best default timeout for tenant migration blocking phase
- Closed