阅读有关“ linearizable”的问题

3.4 版的新功能。

该查询返回的数据反映了在读取操作开始之前完成的所有成功的多数确认写入。在返回结果之前，查询可以 await 并发执行的写入传播到大多数副本集成员。

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

在writeConcernMajorityJournalDefault设置为false的情况下，MongoDB 在确认写入之前不会 awaitw: "majority"写入磁盘日志上。这样，如果给定副本集中的大多数节点发生瞬时丢失(例如崩溃和重新启动)，则majority写操作可能会回滚。

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

可线性化的读取关注保证仅在读取操作指定唯一标识单个文档的查询过滤器时适用。

Tip

万一大多数数据承载成员不可用，请始终将maxTimeMS与可线性化的读取注意事项一起使用。 maxTimeMS确保该操作不会无限期地阻塞，而是确保如果无法满足读取要求，则该操作将返回错误。

因果一致的会话

阅读关注linearizable无法用于因果一致的会话。

实时订单

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

阅读您自己的文章

在版本 3.6 中更改。

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

在 MongoDB 3.6 之前，您必须以{ w: "majority" }写入关注度发出写入操作，然后对读取操作使用"majority"或"linearizable"读取关注度，以确保单个线程可以读取自己的写入。

Performance Comparisons

与"majority"不同，"linearizable"读关注与辅助成员确认读操作正在从主要对象读取，该操作能够以{ w: "majority" }写关注来确认写。 [1]这样，具有线性化读取关注点的读取可能比具有"majority"或"local"读取关注点的读取慢得多。

万一大多数数据承载成员不可用，请始终将maxTimeMS与可线性化的读取注意事项一起使用。 maxTimeMS确保该操作不会无限期地阻塞，而是确保如果无法满足读取要求，则该操作将返回错误。

For example:

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

db.runCommand( {
     find: "restaurants",
     filter: { _id: 5 },
     readConcern: { level: "linearizable" },
     maxTimeMS: 10000
} )
[1] 在some circumstances中，副本集中的两个节点可能暂时认为它们是主要节点，但是最多，其中一个节点将能够完成{ w: "majority" }写入关注。可以完成{ w: "majority" }写操作的节点是当前主节点，另一个节点是以前的主节点，通常由于network partition而尚未识别其降级。发生这种情况时，尽管已请求读取首选项primary，但连接到先前主服务器的 Client 端仍可能会观察到过时的数据，并且对先前主服务器的新写入最终将回滚。
首页