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

Step up may cause reads at PIT with holes after yielding

    XMLWordPrintable

Details

    • Bug
    • Status: Closed
    • Major - P3
    • Resolution: Fixed
    • None
    • 4.4.0-rc7, 4.2.9, 4.7.0
    • Concurrency
    • None
    • Fully Compatible
    • ALL
    • v4.4, v4.2, v4.0
    • Execution Team 2020-03-23, Execution Team 2020-04-06, Execution Team 2020-05-04, Execution Team 2020-05-18
    • 0

    Description

      When we acquire collection locks with AutoGetCollectionForRead on a secondary, we set the TimestampReadSource on the recovery unit to kLastApplied if we were a secondary at the time. However, when we re-acquire locks after a yield in PlanExecutor, we use the same TimestampReadSource we had when we originally acquired those locks, even we've become a primary since. This is bad for the oplog specifically, because on a primary, the last applied time is not oplog-hole-free, meaning we can read past oplog holes. More in general, we should not read at a PIT if there are still write transactions that may commit at that PIT.

      Suggested fix: Have secondary reads use the kNoOverlap read source instead of kLastApplied, which is std::min(*lastApplied, allDurable). This is the same as kLastApplied while a node is remains secondary, but is equivalent to kAllDurableSnapshot after transition to primary.

      Attachments

        Issue Links

          Activity

            People

              louis.williams@mongodb.com Louis Williams
              geert.bosch@mongodb.com Geert Bosch
              Votes:
              0 Vote for this issue
              Watchers:
              12 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: