ShardServerOpObserver does not correctly identify if it's acting as primary or secondary

XMLWordPrintableJSON

    • Type: Bug
    • Resolution: Fixed
    • Priority: Major - P3
    • 7.0.0-rc0
    • Affects Version/s: 5.0.0, 6.0.0
    • Component/s: None
    • None
    • Fully Compatible
    • ALL
    • Sharding EMEA 2023-04-17
    • 146
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      ShardServerOpObserver uses `isStandaloneOrPrimary` to identify if the observed write was done by this node itself (i.e. primary) or from secondary oplog application.

      However, the implementation of `isStandaloneOrPrimary` is flawed: It uses ReplicationCoordinator::getMemberState, which turns RS_PRIMARY as soon as the node wins the election. However, the newly-elected node may still be draining oplog. In that situation, the observer should still behave in "secondary" mode.

      The correct way to implement `isStandaloneOrPrimary` is to use ReplicationCoordinator::canAcceptWritesFor (which other op_observers already use). `canAcceptWritesFor` will only turn true after oplog has been drained.

            Assignee:
            Jordi Serra Torrens
            Reporter:
            Jordi Serra Torrens
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated:
              Resolved: