[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:
Depends
is depended on by SERVER-56555 Enable drop_collection_sharded.js FSM... Closed
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: SERVER-56040 Changing the behavior of recoverable critical sections on secondary nodes

Generated at Thu Feb 08 05:38:09 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.