-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: None
-
None
-
Cluster Scalability
-
Fully Compatible
-
Cluster Scalability 2024-4-1
Similar to SERVER-87191, Timeseries updates/deletes without shard key using the single shard optimization checks getNShardsOwningChunks, which does not respect atClusterTime chosen for a transaction started with snapshot read concern. This can lead to inconsistent targeting similar to the linked ticket.
The scenario to investigate is:
1. Start transaction with readConcern: snapshot
2. Perform update to some coll so that T1 is now the current timestamp
3. moveChunk for coll2 so that all chunks are on one shard
4. Perform an update on coll2 in the same transaction
In using getNShardsOwningChunks, we may start the transaction with knowledge that coll2 has chunks on multiple shards, but by the time we run step 4 getNShardsOwningChunks will register that there is only 1 shard with chunks for coll2. I'm not sure if this will definitively lead to the same issue in SERVER-87191, but the inconsistent routing throughout a transaction should be addressed.
- is related to
-
SERVER-87197 Investigate error prone chunk manager functions usages
- Closed
-
SERVER-87191 Update without shard key might miss documents
- Closed
-
SERVER-82927 Support retryable time-series updates on single shard sharded collections
- Closed