-
Type:
Task
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
Catalog and Routing
-
None
-
None
-
None
-
None
-
None
-
None
-
None
In order to enable support of authoritative collections we have to handle the case of having an authoritative CSS.
In order to do this the following protocol has to be followed:
- If the versions are comparable then we use that information to determine if the router is stale
- Otherwise, if the router is more recent than us, or if the versions can’t be compared:
- We wait until the shard’s version matches the router’s
- OR we wait until the shard has replicated up to the configTime received and it is majority available, whichever of these two events come first
- Once we’re done waiting, we compare against the current state and if it’s a mismatch then the router is guaranteed to be stale
The comparison checks must also consider a critical section not being present as otherwise we'd be making comparisons mid-way through a change in the CSS.
Note that we must also handle the case of a CSS becoming non-authoritative by the time we finish the wait, in which case we should fallback to the handling done by non-authoritative CSS
- depends on
-
SERVER-119833 Add support for registering a waiter on the CSS shard version
-
- In Code Review
-
-
SERVER-119832 Modify CSS to contain information on whether it is authoritative or not
-
- Closed
-
-
SERVER-119834 Add support for registering a waiter on a given oplog to be replicated and majority available
-
- Closed
-