Loading...

XML

Word

Printable

JSON

Type: Task
Resolution: Fixed
Priority: Major - P3
Fix Version/s: 9.1.0-rc0, 9.0.2
Affects Version/s: None
Component/s: None
Labels:
None

Assigned Teams:

Catalog and Routing
Backwards Compatibility:
Fully Compatible
Backport Requested:

v9.0
Sprint:
CAR Team 2026-07-06, CAR Team 2026-07-20
Linked BF Score:
200
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

is related to

SERVER-131284 [master] Revert SERVER-129223

Closed

related to

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

Closed

SERVER-134194 checkMetadataConsistency reports false MissingDatabaseMetadataInShardCatalog on delayed secondaries

Needs Scheduling

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

Blocked

(1 related to)

Assignee:: Aitor Esteve Alvarado
Reporter:: Aitor Esteve Alvarado
Participants:: Aitor Esteve Alvarado, Githook User, Mothra Jira Bot
Votes:: 0 Vote for this issue
Watchers:: 2 Start watching this issue

Created:: Jun 17 2026 02:57:31 PM UTC
Updated:: Sep 04 2026 07:04:54 AM UTC
Resolved:: Jul 14 2026 10:41:44 AM UTC

Details

Description

Attachments

Issue Links

Activity

People

Dates

PagerDuty