-
Type:
Bug
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: None
-
None
-
Storage Engines - Server Integration
-
Fully Compatible
-
ALL
-
SESIonFire - 2026-05-19, SESIAnimals - 2026-06-02
-
200
-
None
-
None
-
None
-
None
-
None
-
None
-
None
Standby crashes on restart or after a reconnect. Theres a few shapes of this bug:
- After draining a segment and reconnecting, the standby calls clearLogServers() which clears prevSegmentID and this triggers behaviour as though the segment was changed. This makes the log server (wrongly) restream from the beginning. Entries get redelivered, but they're older than what's on disk, we fassert (4017301).
- This crash also happens on cold startup ( _lastMajorityCommittedLSN = 0) when the first log server that responds and we connect to hosts a sealed segment. Startup seeds our state from the checkpoint of that server , segment scan picks that segment and triggers restreaming again and as per above.
- Also, when every log server rejects the LSN with INVALID_START_LSN / START_LSN_TRUNCATED, the standby fatals and crashes instead of recovering.
Fixes in this PR:
- Ensure that we restream only when the segment has actually changed. Know both the old and new segment IDs and compare that they are actually different
- Pick the segment using the larger of the standby's committed LSN and the WT stable ts, so a stale checkpoint start won't affect us
- Skip redelivered oplog entries (compare with <= instead of ==)
- Skip redelivered checkpoint entries when they are <= the latest checkpoint we know about
- When every log server rejects the LSN, refresh topology from CMS and retry instead of crashing
- is related to
-
SERVER-126364 Fix all servers returning stale LSN leading to write unavailability post seal
-
- Closed
-
- related to
-
SERVER-126789 Fix standby state across seals
-
- Closed
-
-
SERVER-128050 Add bounded retries on CMS topology refreshes in standby reconnect loop
-
- Closed
-