-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Replication, Sharding
-
Fully Compatible
-
ALL
-
v4.4
-
Sharding 2020-01-27, Sharding 2020-02-10, Sharding 2020-02-24, Sharding 2020-03-09
-
46
The approach will be to add a uassert/fassert (or possibly fassert when enableTestCommands, else uassert) if mongod receives an incoming command, on an internalClient connection, that accepts RWC, but doesn't have it explicitly specified. The reason is that without it being explicitly specified, this internal command would have the user-defined CWRWC default applied to it, which may not give the desired semantics. This will also ensure that future inter-node communication includes explicit RWC as appropriate (because otherwise tests will fail).
The original approach was to avoid applying RWC defaults to non-replicated namespaces. However, doing this reliably at command dispatch time would require a deep parsing and understanding of all the namespaces that will be touched by the command, which is currently not available and would be hard (perhaps impossible) to add.
Original summary: RWC defaults shouldn't be applied to namespaces that aren't replicated
Original description:
Currently RWC defaults are applied to non-replicated namespaces like the oplog and system.profile, even though this doesn't make sense. In the case of default readConcern majority, this can inhibit initialisation of the oplog fetcher on secondaries during startup, thereby leading to a distributed deadlock where all reads using the default readConcern of majority will not be able to complete (on primaries and secondaries).
- causes
-
SERVER-47043 Read concern set to default when it should be local
- Closed
- is depended on by
-
SERVER-44539 Re-enable "missing RWC" logging
- Backlog
- is related to
-
SERVER-46249 Disallow createIndexes and createCollection from running inside transactions that explicitly specify non-local readConcern
- Closed
-
SERVER-46638 Investigate RWC default implications for FLE in the shell
- Closed
- related to
-
SERVER-53293 DBClientCursor not properly applying readConcern when passed in as an argument
- Closed
-
SERVER-62664 Use explicit read concern in SessionsCollection
- Closed