Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-86583

Non-transactional snapshot read on unsharded collection may execute with mismatched sharding metadata

    • Type: Icon: Bug Bug
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 8.0.0-rc0, 7.0.8, 7.3.2
    • Affects Version/s: 7.0.0
    • Component/s: None
    • None
    • Catalog and Routing
    • Fully Compatible
    • ALL
    • v7.3, v7.0
    • CAR Team 2024-02-19, CAR Team 2024-03-04

      Issue Status as of April 15

      ISSUE DESCRIPTION AND IMPACT

      Reads performed on sharded clusters with readConcern: snapshot and an atClusterTime value may return incomplete results if all of the following are true about the collection being read:

      • It is a sharded collection at either the time of the read or at the atClusterTime.
      • It is dropped after the time atClusterTime.
      • it is re-created as an un-sharded collection after being dropped.

      Note that this may also affect reads within "snapshot sessions" (sessions created with readConcern: snapshot), because these internally make use of readConcern: snapshot with an atClusterTime value.

      DIAGNOSIS AND AFFECTED VERSIONS

      Sharded clusters running MongoDB versions 7.0.0-7.0.7 are affected by this issue.

      REMEDIATION AND WORKAROUNDS

      Upgrade to MongoDB 7.0.8 or avoid depending on readConcern: snapshot with atClusterTime values during the operational activities of dropping sharded collections and re-creating them as un-sharded collections.

      Original description

      SERVER-84723 omitted an anomaly that can occur on non-transactional snapshot reads on unsharded collections.
      Consider the following interleaving:

      • Collection is sharded
      • At T20 the collection is dropped
      • At T30 the collection is recreated as unsharded (and not tracked by the sharding catalog)
      • A client executes a find with readConcern=snapshot + atClusterTime=T10.

      In this case, the find will observe storage engine data as of T10, but the sharding metadata (and routing) will correspond to that of the present. So the find will miss documents.

        1. repro.js
          1 kB
          Jordi Serra Torrens

            Assignee:
            jordi.serra-torrens@mongodb.com Jordi Serra Torrens
            Reporter:
            jordi.serra-torrens@mongodb.com Jordi Serra Torrens
            Votes:
            0 Vote for this issue
            Watchers:
            8 Start watching this issue

              Created:
              Updated:
              Resolved: