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

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

    XMLWordPrintableJSON

Details

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major - P3 Major - P3
    • 7.0.0-rc0
    • 5.0.0, 6.0.0
    • None
    • None
    • Fully Compatible
    • ALL
    • Sharding EMEA 2023-04-17
    • 146

    Description

      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.

      Attachments

        Activity

          People

            jordi.serra-torrens@mongodb.com Jordi Serra Torrens
            jordi.serra-torrens@mongodb.com Jordi Serra Torrens
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: