-
Type: Task
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Sharding
-
Fully Compatible
-
Sharding EMEA 2021-05-03, Sharding EMEA 2021-05-17
In the current implementation the in-memory representation of the CS is only taken on the primary node. Note that we don't have to take it on secondaries when we want to block reads because we clear the filtering metadata.
The main implication of not replicating the behavior of the in-memory CS on all nodes is that every time there is a step down or step up we have to properly handle it:
- For the step down, if we were holding the recoverable CS we have to release the in-memory representation of it.
- For the step up, on drain mode we go through all recoverable CS and retake the in-memory CS.
We believe that if we replicate the behavior of the in-memory CS in all nodes (via the shard server op observer) we won't need to do anything on step up (drain mode) / step down (e.g. DDL POS). However, we will have to implement the rollback of all the operations we do over config.collectionCriticalSections.
- is depended on by
-
SERVER-56555 Enable drop_collection_sharded.js FSM workload in stepdown suites
- Closed