ExportXMLWordPrintableJSON

    • Type: Bug
    • Resolution: Unresolved
    • Priority: Major - P3
    • None
    • Affects Version/s: None
    • Component/s: None
    • Replication
    • ALL
    • None
    • None
    • None
    • None
    • None
    • None
    • None

      Overview

      ReplicationCoordinatorDisaggregatedStorage::produceReplSetGetStatusResponse reports every member
      that is not the current primary with state RS_SECONDARY / stateStr "SECONDARY". The state is
      hard-coded and does not reflect the member's real state, so a node in STARTUP, STARTUP2,
      RECOVERING, or one that is down is still reported as SECONDARY.

      Impact

      hello on the member itself is accurate (secondary: false while in STARTUP2), but clients and
      tools that pick a secondary from replSetGetStatus are misled. In SERVER-135304 the pali_chaos
      harness used replSetGetStatus to find a secondary and sent reads to a restarted node still in
      STARTUP2. Every read was rejected with 13436 NotPrimaryOrSecondary. The harness has since been
      changed to check hello, but any other consumer of stateStr has the same problem.

      Repro

      1. Start a DSC replica set with a primary and one standby.
      2. Hold the standby in STARTUP2 (e.g. failpoint hangBeforeStartingOplogApplicationAfterCheckpointLoad) after a restart.
      3. Run replSetGetStatus on the primary: the standby is reported as SECONDARY.
      4. Run hello on the standby: secondary is false.

      Expected

      replSetGetStatus reports each member's actual state, e.g. from heartbeat data on the primary
      (as ASC does), or at least not SECONDARY for members not known to be SECONDARY.

            Assignee:
            Unassigned
            Reporter:
            Sam Frank
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated: