Read Concern "linearizable"
New in version 3.4.
The query returns data that reflects all successful majority-acknowledged writes that completed prior to the start of the read operation. The query may wait for concurrently executing writes to propagate to a majority of replica set members before returning results.
If a majority of your replica set members crash and restart after the
read operation, documents returned by the read operation are durable if
writeConcernMajorityJournalDefault is set to the default
state 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 the
writes. As such, "majority" write operations could
possibly roll back in the event of a transient loss (e.g. crash and
restart) of a majority of nodes in a given replica set.
You can specify linearizable read concern for read operations on
the primary only.
Linearizable read concern guarantees only apply if read operations specify a query filter that uniquely identifies a single document.
Tip
Always use maxTimeMS with linearizable read concern in case a
majority of data bearing members are unavailable. maxTimeMS
ensures that the operation does not block indefinitely and instead
ensures that the operation returns an error if the read concern
cannot be fulfilled.
Causally Consistent Sessions
Read concern "linearizable" is unavailable for use with
causally consistent sessions.
Aggregation Restriction
You cannot use the $out or the $merge stage
in conjunction with read concern "linearizable". That
is, if you specify "linearizable" read concern for
db.collection.aggregate(), you cannot include either
stages in the pipeline.
Real Time Order
Combined with "majority" write concern,
"linearizable" read concern enables multiple threads to
perform reads and writes on a single document as if a single thread
performed these operations in real time; that is, the corresponding
schedule 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 request acknowledgement.
Prior to MongoDB 3.6, in order to read your own writes you must issue
your write operation with { w: "majority" }
write concern, and then issue your read operation with
primary read preference, and either
"majority" or "linearizable" read concern.
Performance Comparisons
Unlike "majority", "linearizable" read
concern confirms with secondary members that the read operation is
reading from a primary that is capable of confirming writes with
{ w: "majority" } write concern.
[1] As such, reads with linearizable read
concern may be significantly slower than reads with
"majority" or "local" read concerns.
Always use maxTimeMS with linearizable read concern in case a
majority of data bearing members are unavailable. maxTimeMS ensures
that the operation does not block indefinitely and instead ensures that
the 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 } )
| [1] | In some circumstances, two nodes in a replica set
may transiently believe that they are the primary, but at most, one
of them will be able to complete writes with { w:
"majority" } write concern. The node that can complete
{ w: "majority" } writes is the current
primary, and the other node is a former primary that has not yet
recognized its demotion, typically due to a network partition.
When this occurs, clients that connect to the former primary may
observe stale data despite having requested read preference
primary, and new writes to the former primary will
eventually roll back. |