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

Timeseries update/delete without shard key using the single shard optimization may target incorrectly

    • Type: Icon: Bug Bug
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 8.0.0-rc0
    • 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.

            Assignee:
            jason.zhang@mongodb.com Jason Zhang (Inactive)
            Reporter:
            jason.zhang@mongodb.com Jason Zhang (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            9 Start watching this issue

              Created:
              Updated:
              Resolved: