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

Retryable writes may execute more than once in resharding if statements straddle the fetchTimestamp

    XMLWordPrintable

    Details

    • Backwards Compatibility:
      Fully Compatible
    • Operating System:
      ALL
    • Sprint:
      Sharding 2021-03-08
    • Story Points:
      1

      Description

      Donor 1 Donor 2 Coordinator
      Donor 1 chooses minFetchTimestamp ts=10    
      Donor 1 performs retryable write stmtId 1 at ts=20    
      Donor 1 performs retryable write stmtId 2 at ts=30    
        Donor 2 chooses minFetchTimestamp ts=25  
          Coordinator chooses fetchTimestamp ts=25

      leads to a sequence where the recipients won't have written an incomplete stmtId for the retryable write due to the timestamp for stmtId 2 being greater than the fetchTimestamp. This allows the statements from the retryable write to execute a second time on the recipients after the resharding operation has finished.

      {
          aggregate: "transactions",
          pipeline: [
              {$match: {_id: {$gt: <resume lsid>}}},
              {$sort: {_id: 1}},
              {$match: {"lastWriteOpTime.ts": {$lt: <fetchTimestamp>}}},
          ],
          readConcern: {level: "majority", afterClusterTime: <fetchTimestamp>},
          hint: "_id_",
          cursor: {},
      }
      

      The {"lastWriteOpTime.ts": {$lt: <fetchTimestamp>}} clause is what causes stmtId 2 and therefore the entire retryable write to be skipped over by the recipients.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              yuhong.zhang Yuhong Zhang
              Reporter:
              max.hirschhorn Max Hirschhorn
              Participants:
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: