读关注 "linearizable"
最后更新于
最后更新于
3.4版本中的新功能。
该查询返回的数据反映了在开始读操作之前完成的所有成功的经过多数确认的写操作。在返回结果之前,查询可以等待并发执行的写传播到大多数复制集成员。
如果大多数复制集成员在读取操作后崩溃并重新启动,则如果设置为true
的默认 state,则读取操作返回的文档是持久的。
当设置为false
时,MongoDB 不会等待 [w: "majority"
](. 崩溃和重启)的事件中回滚。
您可以仅为主节点上的读操作指定可线性化的读关注。
可线性化读取关注保证仅在读取操作指定唯一标识单个文档的查询过滤器时才适用。
提示
如果大多数数据承载成员不可用,请始终使用带有线性化读取问题的
maxTimeMS
。maxTimeMS
确保操作不会无限期地阻塞,而是确保在无法满足读取关注时操作返回错误。
对于因果一致会话,读关注linearizable不可用。
不能将 或 阶段与read关注点[线性化
](
结合["majority"
]( ["linearizable"
](
更改了3.6版本.
总是使用可线性化读取关注的maxTimeMS,以防大多数数据承载成员不可用。maxTimeMS确保了操作不会无限期地阻塞,相反,它确保了如果读问题不能实现,操作会返回一个错误。
例如:
译者:杨帅
校对:杨帅
从 MongoDB 3.6 开始,如果写请求确认,则可以使用 来读取您自己的写入。
在MongoDB 3.6之前,你必须使用 [{ w: "majority" }
](") 写关注点来发布写操作,然后使用["majority"
](") 或["linearizable"
](") 的读关注点来执行读操作,以确保单个线程可以读取自己的写操作。
与“多数”不同,“可线性化”的读关注点向辅助成员确认读操作是从能够用 [{ w: "majority" }
](") 写关注点确认写操作的主成员读取的。这样,线性化的读取可能比“多数”或“局部”读取要慢得多。
与["majority"
]( [{ w: "majority" }
]() 这样,线性化的读取可能比 ["majority"
](") 或 ["local"
](
在某些情况下,一个复制集中的两个节点可能暂时认为它们是主节点,但它们中的一个最多能够完成[{ w: "majority" }
]( w: "majority" }`](