Loading...

XML

Word

Printable

JSON

Type: Task
Resolution: Unresolved
Priority: Major - P3
Fix Version/s: None
Affects Version/s: None
Component/s: None
Labels:
None

Assigned Teams:

Catalog and Routing
Sprint:
CAR Team 2026-07-06, CAR Team 2026-07-20
CAR Domain/s:

🟦 Shard Catalog

Aha! Reference:
None
Tracking Level:
None
Risk Status:
None
Exec Notes:
None
Goal Name(s):
None
Goal Link:
None

_shardsvrCheckMetadataConsistencySecondaryParticipant is called on secondaries and should perform similar checks to the primary counterpart, but it requires a stable catalog. By default, it runs with "afterClusterTime", but this could hide issues on lagged secondaries. This task is to investigate if it possible to run _shardsvrCheckMetadataConsistencySecondaryParticipant on lagged secondaries by taking the appropriate snapshots.

depends on

SERVER-130395 Change ShardingCatalogClient API to take ReadConcernArgs instead of ReadConcernLevel

Closed

SERVER-130697 Honor atClusterTime in Shard::_exhaustiveFindOnConfig()

Closed

related to

SERVER-130787 checkMetadataConsistency on secondary can report false positive due to CSR being newer than durable read timestamp

In Progress

SERVER-130947 Take a consistent CollectionMetadata in CMC on delayed secondaries

In Progress

Assignee:: Aitor Esteve Alvarado
Reporter:: Aitor Esteve Alvarado
Participants:: Aitor Esteve Alvarado
Votes:: 0 Vote for this issue
Watchers:: 1 Start watching this issue

Created:: Jun 17 2026 02:57:31 PM UTC
Updated:: Jul 09 2026 02:33:06 PM UTC

Details

Description

Attachments

Issue Links

Activity

People

Dates