MongoDB运维与开发(9)---readConcern

//

MongoDB运维与开发(9)---readConcern

//

readConcern产生背景：

MongoDB的写请求写入Primary， secondary从Primary自动获取并且应用oplog来保持和主库的同步， MongoDB 允许用户从Primary 或者 secondary 读取数据。但读数据可能存在以下问题：

1、如果用户从secondary读，但secondary还没有跟上Primary，就会导致读取了老数据

2、如果用户从primary读到数据，但在该数据复制到secondary 之前crash 了，就会导致用户读取到"脏数据"。

MongoDB在3.6版本中引入了readConcern这个参数，readConcern决定在读取数据的时候，到底能够读取到哪个版本的数据。

今天主要看看概念性质的东西，下篇文章中会给出相应的例子。

readConcern可选的值包含：

local、available、majority、linearizable、snapshot

下面来看这几个值的含义：

1、local：查询从实例返回数据，不能保证数据已经写入大多数副本集成员

默认从主库读如果本次读取使用了causally consistent(这里仅知道这个概念就行，关于这个概念，后续会补充) ，则默认在从库读

2、available：查询从实例返回数据，不能保证数据已经写入大多数副本集成员

如果本次读取没有使用causally consistent ，则默认在从库读如果本次读取使用了causally consistent ，则不能使用available

对于分片的副本集来说，available模式提供了最低的读取延迟，但是这个优点是以数据的一致性为代价的，因为它可能返回一个孤立的文档。

3、majority：查询结果返回被副本集的大多数成员确认的数据，读操作返回的文档是持久化的

要想使用majority这个模式的readConcern，MongoDB必须使用wireTiger存储引擎。

4、linearizable：该查询返回的数据返回在读取操作开始之前完成的所有成功的多数确认写入。查询可能会等待并发执行的写操作传播到大多数副本集成员，然后返回结果。

如果集群中大多数副本集成员崩溃，并且在读取操作后重新启动，这个时候，读取的结果将取决于参数：

writeConcernMajorityJournalDefault

如果writeConcernMajorityJournalDefault设置为默认状态true，则读取操作返回的文档是持久的；

如果将writeConcernMajorityJournalDefault设置为false时，在确认写入之前，MongoDB不会等待数据写入磁盘日志，即使我们配置了w=majority。这样，在给定副本集中大多数节点的瞬时丢失的情况下，多数写入操作可能会回滚(为磁盘中没有日志)。

通常情况下，可以对primary节点配置线性读取如果读取使用了causally consistent，则无法使用linearizable模式

5、snapshot：适用于多文档事务中的操作。

通常情况下使用较少。后续有用到，再举例说明。

注意：

目前 readConcern 主要用于跟 mongos 与 config server 的交互上使用readConcern 需要配置replication.enableMajorityReadConcern选项只有支持 readCommited 隔离级别的存储引擎才能支持 readConcern，比如 wiredtiger 引擎，而 mmapv1引擎则不能支持。

有帮助的话还希望点下再看哈