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

XMLWordPrintableJSON

    • Type: Bug
    • Resolution: Unresolved
    • Priority: Major - P3
    • None
    • Affects Version/s: 9.0.0-rc0
    • Component/s: None
    • Catalog and Routing
    • ALL
    • CAR Team 2026-07-20
    • 馃煡 DDL
    • None
    • None
    • None
    • None
    • None
    • None

      Since SERVER-129220, we run the checkMetadataConsistency command on secondaries: The primary's checkMetadataConsistency, while holding the DDL lock, will send a checkMetadataConsistency to the secondaries, with snapshot read concern at Tdurable=majorityCommitPoint.

      聽

      However while this happens, the secondary's CSR can advance past that point. For example via a chunk migration (which doesn't require the DDL lock) we can commit the first chunk on the shard, then refresh the secondary CSR via a read. At this point the CSR reflects a newer state than Tdurable.

      聽

      When we run the consistency check on the secondary, we will see the sharded collection in the CSR and expect to find the collection entry in the durable authoritative shard catalog, but it won't be found at Tdurable, so we will report a false positive InconsistentShardCatalogCollectionMetadata inconsistency.

        1. repro-SERVER-130787.patch
          3 kB

            Assignee:
            Jordi Olivares Provencio
            Reporter:
            Joan Bruguera Mic贸
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: