-
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
- Start a DSC replica set with a primary and one standby.
- Hold the standby in STARTUP2 (e.g. failpoint hangBeforeStartingOplogApplicationAfterCheckpointLoad) after a restart.
- Run replSetGetStatus on the primary: the standby is reported as SECONDARY.
- 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.
- related to
-
SERVER-135304 Disagg: unexplained multi-second write outages (NotPrimaryOrSecondary) outside any injected fault window
-
- Closed
-