• "linearizable"

Read Concern "linearizable"

New in version 3.4.

The query returns data that reflects all successfulmajority-acknowledged writes that completed prior to the start of theread operation. The query may wait for concurrently executing writes topropagate to a majority of replica set members before returning results.

If a majority of your replica set members crash and restart after theread operation, documents returned by the read operation are durable ifwriteConcernMajorityJournalDefault is set to the defaultstate of true.

With writeConcernMajorityJournalDefault set to false,MongoDB does not wait for w: "majority"writes to be written to the on-disk journal before acknowledging thewrites. As such, majority write operations couldpossibly roll back in the event of a transient loss (e.g. crash andrestart) of a majority of nodes in a given replica set.

You can specify linearizable read concern for read operations onthe primary only.

Linearizable read concern guarantees only apply if readoperations specify a query filter that uniquely identifies asingle document.

Tip

Always use maxTimeMS with linearizable read concern in case amajority of data bearing members are unavailable. maxTimeMSensures that the operation does not block indefinitely and insteadensures that the operation returns an error if the read concerncannot be fulfilled.

Causally Consistent Sessions

Read concern linearizable is unavailable for use withcausally consistent sessions.

Aggregation Restriction

You cannot use the $out or the $merge stagein conjunction with read concern "linearizable". Thatis, if you specify "linearizable" read concern fordb.collection.aggregate(), you cannot include eitherstages in the pipeline.

Real Time Order

Combined with "majority" write concern,"linearizable" read concern enables multiple threads toperform reads and writes on a single document as if a single threadperformed these operations in real time; that is, the correspondingschedule for these reads and writes is considered linearizable.

Read Your Own Writes

Changed in version 3.6.

Starting in MongoDB 3.6, you can use causally consistent sessions to read your own writes, if the writes requestacknowledgement.

Prior to MongoDB 3.6, you must have issued your write operation with{ w: "majority" } write concern and thenuse either "majority" or "linearizable"read concern for the read operations to ensure that a single thread canread its own writes.

Performance Comparisons

Unlike "majority", "linearizable" readconcern confirms with secondary members that the read operation isreading from a primary that is capable of confirming writes with{ w: "majority" } write concern.[1] As such, reads with linearizable readconcern may be significantly slower than reads with"majority" or "local" read concerns.

Always use maxTimeMS with linearizable read concern in case amajority of data bearing members are unavailable. maxTimeMS ensuresthat the operation does not block indefinitely and instead ensures thatthe operation returns an error if the read concern cannot be fulfilled.

For example:

db.restaurants.find( { _id: 5 } ).readConcern("linearizable").maxTimeMS(10000)
 
db.runCommand( {
     find: "restaurants",
     filter: { _id: 5 },
     readConcern: { level: "linearizable" },
     maxTimeMS: 10000
} )