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

What is the timestamp used in snapshot distributed transaction? All durable or atClusterTime?

    XMLWordPrintable

    Details

    • Type: Question
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Community Answered
    • Affects Version/s: 4.4.6
    • Fix Version/s: None
    • Component/s: None

      Description

      The transaction with snapshot read concern provides ACID properties for users.

      As I known, it is based on the timestamp transaction in wiredtiger.

      A question makes me puzzled that what is the timestamp used in snapshot distributed transaction? 

      When I refered to the document, it shows

       

      From Shard Internals in GitHub

      Snapshot read concern will choose a snapshot from which the transaction will read. If it is specified with an `atClusterTime` argument, then that will be used as the transaction's read timestamp. If `atClusterTime` is not specified, then the read timestamp of the transaction will be the [`all_durable`]timestamp when the transaction is started, which ensures a snapshot with no oplog holes.

      If the mongodb is deployed in relicat set, the snapshot transaction reads data before all_durable timestamp which ensures a snapshot with no oplog holes.

      However, in shard deployment, each shard has its own all_durable timestamp, but the meaning of "snapshot" requires that each shard reads from the same timestamp, I think it is the atClusterTime from mongos and it is the clusterTime in mongos, right?

      However, this will not lead to holes in the oplog?

       

       

        Attachments

          Activity

            People

            Assignee:
            dmitry.agranat Dmitry Agranat
            Reporter:
            tsunaouyang@gmail.com Ouyang Tsuna
            Participants:
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: