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

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

    • Type: Icon: Bug Bug
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 4.0.22
    • Affects Version/s: 4.0.11
    • Component/s: Sharding
    • None
    • Fully Compatible
    • ALL
    • Sharding 2020-11-30

      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.

            Assignee:
            alex.taskov@mongodb.com Alexander Taskov (Inactive)
            Reporter:
            alex.taskov@mongodb.com Alexander Taskov (Inactive)
            Votes:
            0 Vote for this issue
            Watchers:
            10 Start watching this issue

              Created:
              Updated:
              Resolved: