Major - P3 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.
- related to
-
SERVER-84723 Sharded multi-document transactions can observe partial effects of concurrent DDL operations
-
- Closed
-