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

`readConcern: snapshot` cause many write conflicts

    XMLWordPrintable

    Details

    • Type: Question
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Gone away
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Storage
    • Labels:
      None
    • Sprint:
      Repl 2019-08-12, Repl 2019-08-26, Repl 2019-09-09, Repl 2019-09-23, Repl 2019-10-07, Repl 2019-10-21, Repl 2019-11-04, Repl 2019-11-18, Repl 2019-12-02, Repl 2019-12-16

      Description

      Coming from SERVER-39672.

      In one our transaction performance test on mongodb 4.0.9, we saw many write conflict errors and the write conflict error does not indicate which document it is conflicting on.

      The environment is only running with one primary mongodb 4.0.9 with no secondary nodes in one machine.

      • we tested in mongodb 4.0.10 later and everything passed
      • then, we switched to `readConcern: local' in 4.0.9 and everything passed too
      • our job mostly just does append operations and does not have any real write conflicts so that seeing many write conflicts is strange to us

      We are curious why changing `readConcern` levels can change write conflict behavior. In theory, they should behave the same and it is more about timing. Or, the server should throw a different error.

      As the production system will use `readConcern: snapshot`, we are worried whether we might see this issue back in production?

      Can we get an explanation what is the relationship between readConcern and write conflict errors?

      Thanks,

       

        Attachments

          Activity

            People

            Assignee:
            siyuan.zhou Siyuan Zhou
            Reporter:
            wei wei
            Participants:
            Votes:
            0 Vote for this issue
            Watchers:
            15 Start watching this issue

              Dates

              Created:
              Updated:
              Resolved: