Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-56040

Changing the behavior of recoverable critical sections on secondary nodes

    • 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:

      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.

            Assignee:
            sergi.mateo-bellido@mongodb.com Sergi Mateo Bellido
            Reporter:
            sergi.mateo-bellido@mongodb.com Sergi Mateo Bellido
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: