读关注 (read concern) `"linearizable"`

"linearizable"

该查询返回的数据反映了在读取操作开始之前完成的所有成功的多数已确认的写入操作。该查询可能会等待并发执行的写入操作的数据复制到多数副本集成员之后，再返回结果。

如果多数副本集成员在读操作后崩溃并重新启动，且 writeConcernMajorityJournalDefault 设置为默认状态 true，则读操作返回的文档是持久化的。

将 writeConcernMajorityJournalDefault 设置为 false 时，MongoDB 不会等待 w: "majority" 写入在写入到磁盘日志后才确认写入。例如，"majority" 写操作可能会在给定副本集中的大部分节点发生临时断连（例如崩溃和重启）的情况下回滚。

您只能为primary上的读取操作指定线性化读关注。

仅在读操作指定唯一标识单个文档的查询筛选器时，才适用线性化读关注保证。

提示

始终将maxTimeMS与线性化读关注一起使用，以防大多数数据承载成员不可用。maxTimeMS确保操作不会无限期受阻，而是确保操作在无法满足读关注时返回错误。

因果一致的会话

读关注 "linearizable"不可用于因果一致的会话。

聚合限制

您不能将$out $merge或阶段与读关注"linearizable" 结合使用。也就是说，如果您为"linearizable" db.collection.aggregate()指定读关注，则不能在管道中包含任一阶段。

实时顺序

与"majority"写关注结合， "linearizable"读关注使多个线程能够对单个文档执行读写，就像单个线程实时执行这些操作一样；也就是说，这些读取和写入的相应计划被认为是可线性化的。

读取自己的写入

3.6 版本中的更改。

从 MongoDB 3.6 开始，如果写入请求确认，您可以使用因果一致的会话来读取您自己的写入。

MongoDB 3之前的版本。 6 ，为了读取您自己的写入，您必须使用{ w: "majority" }写关注发出写入操作，然后使用primary读取偏好以及"majority"或"linearizable"读关注发出读取操作。

性能比较

与"majority"不同， "linearizable"读关注会与从节点成员确认读取操作正在从主节点读取，而主节点能够使用{ w: "majority" }写关注确认写入操作。 [ 1 ]因此，具有可线性化读关注的读取可能比具有"majority"或"local"读关注的读取慢得多。

例如：

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

[1]	在某些情况下，副本集中的两个节点可能会暂时认为它们是主节点，但最多只能有其中一个节点能够完成具有`{ w: "majority" }`写入关注的写入操作。可以完成`{ w: "majority" }`写入操作的节点是当前主节点，另一个节点是尚未识别其降级（通常是由于网络分区）的前主节点。发生这种情况时，尽管已请求读取偏好`primary`，但连接到前主节点的客户端可能会观察到过时数据，并且对前主节点的新写入操作最终将回滚。

← 读关注 (read concern) "majority"

读关注 (read concern) "snapshot" →