Write Concern写关注
在本页面
写关注描述了MongoDB请求对独立mongod
或复制集或分片群集进行写操作的确认级别。在分片群集中,mongos
实例会将写关注事项传递给分片。
[success] Note
对于多文档事务,可以在事务级别而不是在单个操作级别设置写关注。不要为事务中的各个写操作显式设置写关注点。
编写关注规范
写关注可包括以下字段:
w 选项
w
选项请求确认写操作已传播到指定数量的mongod实例或具有指定标记的mongod实例。
使用w
选项,可以使用以下**w:<value
>**写入问题:
也可以看看
j 选项
该j
选项要求MongoDB确认写入操作已写入磁盘日志中。
| |
[success] Note
指定一个写入关注点,该关注点包含到正在运行且没有日志记录的 实例中会产生错误。
j: true
mongod
如果启用日记功能,则可能暗示。的 副本集配置设置确定的行为。有关详细信息,请参见 确认行为。[
w: "majority"
](https://docs.mongodb.com/manual/reference/write-concern/#writeconcern."majority")`j: true[
writeConcernMajorityJournalDefault`](https://docs.mongodb.com/manual/reference/replica-configuration/#rsconf.writeConcernMajorityJournalDefault).如果日志是启用的,[
w: "majority"
](https://docs.mongodb.com/master/reference/write-concern/#writeconcern."majority") 可能意味着j:true。writeConcernMajorityJournalDefault
复制集配置设置决定了行为。有关详细信息,请参阅确认行为 。
wtimeout
此选项指定写入问题的 time 限制(以毫秒为单位)。 wtimeout
仅适用于大于1
的w
值。
wtimeout
导致写入操作返回到指定限制后的错误,即使所需的写入关注最终会成功。当这些写操作 return 时,MongoDB 不会撤消在写入关注超过wtimeout
time 限制之前执行的成功数据修改。
如果未指定wtimeout
选项且写入关注的 level 无法实现,则写入操作将无限期阻止。指定0
的wtimeout
value 等同于没有wtimeout
选项的写入问题。
确认行为
独立
独立mongod
应用程序在应用了内存中的写入之后或写入磁盘日志后会确认写入操作。下表列出了独立服务器的确认行为以及相关的写入问题:
|
|
| |
| 在记忆中 | 磁盘日志 | 在内存中 |
| 磁盘日志(如果与日志一起运行) | 磁盘日志 | 在内存中 |
[success] Note
随着
writeConcernMajorityJournalDefault
设置为false
,MongoDB的不等待 写入承认写之前被写入到磁盘上的日志。这样,在给定副本集中的大多数节点出现瞬时丢失(例如崩溃和重新启动)的情况下,写操作可能会回滚。[w: "majority"
](https://docs.mongodb.com/manual/reference/write-concern/#writeconcern."majority")`majority`
复制集
指定给w的值确定返回成功之前必须确认写入的复制集成员的数量。对于每个合格的复制集成员,j 选项确定成员是在内存中应用写操作之后还是在写到磁盘日志上之后是否确认写。
w: "majority"
复制集的任何带有数据的投票成员都可以对["majority"
](https://docs.mongodb.com/manual/reference/write-concern/#writeconcern."majority")写操作进行写确认。
下表列出了成员何时可以基于j值确认写入:
| 确认取决于 |
| 确认需要对磁盘日志进行写入操作。 |
| 确认需要在内存中进行写入操作。 |
[success] Note
行为细节,参见 w: "majority" Behavior.
w: <number
>
复制集的任何承载数据的成员都可以参与w:<number>
写操作的写确认。
下表列出了成员何时可以基于j值确认写入:
| 确认需要在内存中进行写操作(j: false)。 |
| 确认需要将操作写入磁盘日志。 |
| 确认需要在内存中进行写操作。 |
注意
隐藏, 延迟和优先级为0 的成员可以确认
w:<number>
写操作。延迟的辅助程序可以不早于配置的slaveDelay返回写确认。
因果一致的会话和写问题
使用因果一致的客户机会话,客户机会话仅在以下情况下保证因果一致性:
相关的写操作使用[
"majority"
](https://docs.mongodb.com/manual/reference/write-concern/#writeconcern."majority") 写关注。
有关详细信息,请参见因果一致性。
w: "majority"
的行为
w: "majority"
的行为writeConcernMajorityJournalDefault
设置为false,MongoDB不等待[w: "majority"
](https://docs.mongodb.com/master/reference/write-concern/#writeconcern."majority") 写入被写入到磁盘日志之前,确认写入,因此,在给定复制集中的大多数节点出现短暂损失(例如崩溃和重新启动)时,大多数写操作可能会回滚。隐藏的, 延迟的, and priority 0的成员,成员数为[n]。投票大于0可以确认[
"majority"
](https://docs.mongodb.com/master/reference/write-concern/#writeconcern."majority") ”写操作。
计算关注的多数
提示
从版本4.2.1开始,
rs.status()
返回writeMajorityCount
包含计算出的多数数的 字段。
写入关注的多数["majority"
](https://docs.mongodb.com/manual/reference/write-concern/#writeconcern."majority")由以下值中的较小者计算得出:
所有投票成员(包括仲裁员)中的大多数
所有带有数据的投票成员的数量。
[warning] 警告
如果计算出的多数数等于所有带有数据的投票成员的人数(例如,由3个成员组成的主要-次要仲裁员部署),则写关注 [
"majority"
](https://docs.mongodb.com/manual/reference/write-concern/#writeconcern."majority")可能会超时,或者如果有数据的投票成员则永远不会得到承认掉线或无法到达。如果可能,请使用带有数据的投票成员而不是仲裁者。
例如,考虑:
具有3个投票成员的复制集,主要-次要(PSS):
所有投票成员中大多数为2。
所有有数据投票的成员人数为3。
计算得出的多数为2,最小值为2和3。写入必须传播到主要对象和辅助对象之一,["majority"
](https://docs.mongodb.com/manual/reference/write-concern/#writeconcern."majority")以向客户端确认写入问题。
复制集包含3个投票成员,主要-次要仲裁员(PSA)
所有投票成员中大多数为2。
所有有数据投票的成员人数为2。
计算得出的多数为2,为2和2的最小值。由于该写操作只能应用于数据承载成员,因此该写操作必须传播到主要对象和辅助对象,["majority"
](https://docs.mongodb.com/manual/reference/write-concern/#writeconcern."majority")以向客户端确认写问题。
提示
避免在a (p - a)或其他拓扑结构中使用“多数”写关注点,这些拓扑结构要求所有支持数据的投票成员都可用来确认写操作。想要使用**“majority”**写关注点的持久性保证的客户应该部署不需要所有数据承载投票成员可用的拓扑(例如P-S-S)。
写问题出处
从4.4版本开始,MongoDB跟踪写关注点的来源,它表示一个特定的写关注点的来源。您可能会在getLastError
指标、write concern error对象和MongoDB日志中看到显示出处的信息。
下表显示了可能的写问题provenance值及其重要性:
Provenance | Description |
---|---|
| 写关注点是在应用程序中指定的。 |
| 写关注点源自自定义的默认值。参见 |
| 写关系起源于复制集的设置 |
| 在没有其他所有写关注规范的情况下,写关注源自服务器。 |
译者:杨帅 张琦
校对:杨帅
最后更新于