- Reference >
mongoShell Methods >- Cursor Methods >
- cursor.readConcern()
cursor.readConcern()¶
On this page
Definition¶
-
cursor.readConcern(level)¶ New in version 3.2.
Specify a read concern for the
db.collection.find()method.The
readConcern()method has the following form:The
readConcern()method has the following parameter:Parameter Type Description levelstring Read concern level.
Possible read concern levels are:
"local". This is the default read concern level for read operations against primary and read operations against secondaries when associated with causally consistent sessions."available". This is the default for reads against secondaries when when not associated with causally consistent sessions. The query returns the instance’s most recent data."majority". Available for replica sets that use WiredTiger storage engine."linearizable". Available for read operations on theprimaryonly.
For more formation on the read concern levels, see Read Concern Levels.
Considerations¶
"majority" Read Concern¶
To use read concern level of "majority", replica
sets must use WiredTiger storage engine.
You can disable read concern "majority" for a deployment
with a three-member primary-secondary-arbiter (PSA) architecture;
however, this has implications for change streams (in MongoDB 4.0 and
earlier only) and transactions on sharded clusters. For more information,
see Disable Read Concern Majority.
Read Your Own Writes¶
Starting in MongoDB 3.6, you can use causally consistent sessions to read your own writes, if the writes request acknowledgement.
Prior to MongoDB 3.6, you must have issued your write operation with
{ w: "majority" } write concern and then
use either "majority" or "linearizable"
read concern for the read operations to ensure that a single thread can
read its own writes.
Linearizable Read Concern Performance¶
When specifying linearizable read concern, always use maxTimeMS() in case
a majority of data bearing members are unavailable.
See also