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.
- is caused by
-
SERVER-40535 Possibility to get a non-existent key if using ReadConcern level:local when reading signing keys in ReplicaSet
-
- Closed
-
- related to
-
-
- Closed
-