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

Linearizable reads can occasionally read with wrong read source

    XMLWordPrintableJSON

Details

    • Bug
    • Status: Closed
    • Major - P3
    • Resolution: Fixed
    • 5.0.9, 6.0.0-rc10, 6.1.0-rc0
    • 5.0.13, 6.0.2, 6.1.0-rc0
    • None
    • None
    • Fully Compatible
    • ALL
    • v6.0, v5.0
    • Execution Team 2022-08-08, Execution Team 2022-08-22

    Description

      Linearizable reads are supposed to happen only on a writable primary with a read source of kNoTimestamp. Because of a race, these reads may enter AutoGetCollectionForRead on a secondary or primary in catch-up mode. Before SERVER-55443, this would result in an fassert as they attempted to read at kNoTimestamp on the non-writable node. After SERVER-55443, there is no invariant, but they may read at kNoTimestamp on a node which is in the middle of applying oplog. Most of the time this will fail when the node attempts to do the no-op write when the read is finished, but if the node completes step-up before that happens, it may succeed. Because linearizable reads are supposed to be for single documents only, this should usually be OK (no inconsistency will be observable) but it is bad practice anyway.

      Instead of either reading at kNoTimestamp on a secondary, or hitting an fassert, a linearizable read should uassert with NotWritablePrimary when it would otherwise open a snapshot on a non-writable node.

      Attachments

        Issue Links

          Activity

            People

              henrik.edin@mongodb.com Henrik Edin
              matthew.russotto@mongodb.com Matthew Russotto
              Votes:
              0 Vote for this issue
              Watchers:
              10 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: