-
Type:
Improvement
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
None
-
Storage Engines - Server Integration
-
None
-
None
-
None
-
None
-
None
-
None
-
None
Since the changes in SERVER-127495, we now never should be able to hit this path where we are disconnecting due to waiting for matlag to catch up. The changes in SERVER-127495 meant that where we previously waited for materialisation to catch up and this block of code was our subsequent exit once we had caught up, we now disconnect straight away even if mat lag is behind, and we trust our bookeeping of state like domain specific committed LSNs to help us catch up from the right spot. The below code block should be investigated, and (highly) possibly removed.
if (_lastSealedLogStateSegmentAndCommittedPhylogLsn &&
_lastSealedLogStateSegmentAndCommittedPhylogLsn->first ==
entryOrSkip.log_segment_id().segment_id() &&
materializedLsn >= _lastSealedLogStateSegmentAndCommittedPhylogLsn->second) {
LOGV2(10985535,
"Materialized LSN has caught up with committed phylog LSN in the sealed log "
"segment. Disconnecting from log service.",
"logSegmentID"_attr = entryOrSkip.log_segment_id(),
"lastCommittedPhyLogLsn"_attr =
_lastSealedLogStateSegmentAndCommittedPhylogLsn->second,
"materializedLsn"_attr = materializedLsn);
_setLastCompletedSealedSegmentId(entryOrSkip.log_segment_id().segment_id(),
"standby loop materialized offset seal"_sd);
LOGV2_DEBUG(12678901,
1,
"Retiring prior segment zones at materialized offset seal",
"retireKey"_attr = entryOrSkip.log_segment_id().segment_id() - 1,
"currentConnectionSegmentId"_attr =
_connection.synchronize()->segmentId);
_topology.retirePriorSegment(entryOrSkip.log_segment_id().segment_id() - 1);
// _resetConfig() is deferred until after the outer entry loop to avoid
// clearing zone-to-cell mappings while subsequent entries still need them.
result.shouldStopReadLog = true;
break;
}