[SERVER-56040] Changing the behavior of recoverable critical sections on secondary nodes Created: 12/Apr/21 Updated: 29/Oct/23 Resolved: 12/May/21 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | 5.0.0-rc0 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Sergi Mateo Bellido | Assignee: | Sergi Mateo Bellido |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | PM-1965-Cleanup | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Sprint: | Sharding EMEA 2021-05-03, Sharding EMEA 2021-05-17 | ||||||||
| Participants: | |||||||||
| Description |
|
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:
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. |
| Comments |
| Comment by Githook User [ 12/May/21 ] |
|
Author: {'name': 'Sergi Mateo Bellido', 'email': 'sergi.mateo-bellido@mongodb.com', 'username': 'smateo'}Message:
|