WiredTiger supports multiple readConcern levels. Just like writeConcern, which is supported by every storage engine in MongoDB, with readConcern we can customize how many servers in a replica set must acknowledge the query results for the document to be returned in the result set.
Available options for read concern are as follows:
- local: Default option. Will return most recent data from the server. Data may or may not have propagated to the other servers in a replica set and we run the risk of a rollback.
- linearizable:
- Only applicable for reads from the primary
- Only applicable in queries that return a single result
- Data returns satisfies two conditions:
- majority writeConcern
- Data was acknowledged before the start of the read operation
In addition, if we have set writeConcernMajorityJournalDefault to true, we are guaranteed that data won't get rolled back.
If we have set writeConcernMajorityJournalDefault to false, MongoDB will not wait for majority writes to be durable before acknowledging the write. In this case, our data may be rolled back in the event of a loss of a member from the replica set.
- majority: Data returned has already been propagated and acknowledged from the majority of the servers before read has started
We need to use maxTimeMS when using linearizable and majority read concern levels in case we can't establish majority writeConcern to avoid blocking forever waiting for the response. In this case, the operation will return a timeout error.
local and linearizable read concerns are available for MMAPv1 as well.