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

KeysCollectionClientDirect should check if majority read concern is supported by storage engine

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major - P3
    • Resolution: Fixed
    • Affects Version/s: 4.0.11
    • Fix Version/s: 4.0.22
    • Component/s: Sharding
    • Labels:
      None
    • Backwards Compatibility:
      Fully Compatible
    • Operating System:
      ALL
    • Sprint:
      Sharding 2020-11-30

      Description

      Issue Status as of Dec 16, 2020

      ISSUE DESCRIPTION AND IMPACT

      When running the deprecated MMAPv1 storage engine in a replica set, attempts for mongod to refresh its set of signing keys from local storage silently fail. This prevents the mongod from signing new cluster times and validating the signatures of existing cluster times.

      • Being unable to sign new cluster times prevents causal consistency from being used by clients.
      • Being unable to validate the signatures of existing cluster times causes all client requests to be rejected with an error.

      DIAGNOSIS AND AFFECTED VERSIONS

      This affects versions of 4.0 starting from 4.0.11 through 4.0.21 inclusive, which are running with the deprecated MMAPv1 storage engine (using the --storageEngine mmapv1 startup option). Operations run on the cluster will fail with a "No Keys Found" errmsg. For example:

      > db.runCommand({isMaster: 1})
      {
          "ok" : 0,
          "errmsg" : "Cache Reader No keys found for HMAC that is valid for time: { ts: Timestamp(1606144194, 9) } with id: 6898336773005377537",
          "code" : 211,
          "codeName" : "KeyNotFound"
      }
      

      REMEDIATION AND WORKAROUNDS

      A fix is included in the 4.0.22 production release.

      Affected users unable to upgrade or switch to the WiredTiger storage engine can start mongod with --enableMajorityReadConcern=false as a workaround.

      This command line option normally has no effect for the MMAPv1 storage engine. But it does avoid the bug in affected versions, allowing mongod to successfully refresh its set of signing keys from local storage.

      Original Description

      Currently, this code checks if majority read concern is enabled by the server parameter. It should instead check that the storage engine supports it. In the current state, causal consistency will not work with the mmapv1 storage engine as the server will not return operationTime and $clusterTime.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              alex.taskov Alexander Taskov
              Reporter:
              alex.taskov Alexander Taskov
              Participants:
              Votes:
              0 Vote for this issue
              Watchers:
              10 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: