mongod在哪个版本中的默认写关注是什么?

问题描述

我在 mongodb的文档中找不到，默认的写关注点是什么，如何定义确认的写入".似乎在所有不同的mongodb版本中都已更改，如 v3.2文档所示例如:

I could not find in mongodb's documentation what's the default write concern and how an "acknowledged write" is defined.It seems that this have changed throughout the different mongodb versions as shows the v3.2 documentation for example:

或者:

或者:

此外，我想知道多数"是指 v3.2文档:

Also, I'm wondering that "majority" refers to all voting nodes in v3.2 documentation :

这是否意味着即使是仲裁员也因为他们是投票节点而计数?因此，例如，如果我有一个由2个数据承载节点加上1个仲裁器组成的replSet，则即使有1个数据承载节点发生故障，因为剩余的数据承载节点已确认该写入，所以写关注为多数"的写操作将成功和仲裁者，因此占多数?

Does this mean that even arbiters count since they are voting nodes? So, for example, if I have a replSet consisting of 2 data bearing nodes plus 1 arbiter, a write operation with write concern "majority" would succeed even if 1 data bearing node went down because the write was acknowledged by the remaining data bearing node and the arbiter, hence the majority?

推荐答案

MongoDB中的默认写关注点是w:1，最早可追溯到2012年的MongoDB 2.2.

The default write concern in MongoDB has been w:1 from as far back as MongoDB 2.2 in 2012.

在当前的MongoDB版本(3.2.6和更高版本)中，可以使用三种不同的设置来设置写关注:

There are three different settings you can use to setup write concern in current MongoDB versions (version 3.2.6 and newer):

• w设置:多少个节点应在声明成功之前确认该写入.默认值为1，表示主节点的确认就足够了.
• j设置:必须先记录日志，然后才能确认?默认值取决于writeConcernMajorityJournalDefault.
• writeConcernMajorityJournalDefault :如果为写操作指定w:majority写关注设置而不设置j，则隐含的j值是多少?默认值为true(在确认之前，应该在大多数投票节点中记录日志).

• w setting: how many nodes should acknowledge the write before declaring it a success. Default is 1, meaning the primary node's acknowledgement is sufficient.
• j setting: do the writes must be journaled before acknowledged? Default depends on writeConcernMajorityJournalDefault.
• writeConcernMajorityJournalDefault: if you specify w:majority write concern setting for your writes without setting j, what is the implied j value? Default is true (writes should be journaled in the majority of the voting nodes before it is acknowledged).

还有一个 wtimeout设置来配置很长的MongoDB在通知客户端未确认写入之前，应等待写入问题得到满足.否则，等待满足写关注的写操作可以永远等待而不是失败.

There is also a wtimeout setting to configure how long MongoDB should wait for write concern to be satisfied before informing the client that the write has not been acknowledged. Otherwise, writes waiting for write concern to be satisfied can wait forever instead of failing.

此处的特殊设置是w:majority.这意味着写入必须传播到要确认的副本集中的多数投票节点(以及它们的日记).在提供良好性能的同时，可以说这是最安全的设置，因为:

The special setting here is w:majority. This means that writes must propagate to the majority of voting nodes (and also to their journals) in a replica set to be acknowledged. This is arguably the safest setting while providing good performance, because:

• 它可以防止发生故障时回退已确认的写入.
• 它调节应用程序的吞吐量，以便它发送副本的速度不会超过副本集可以处理的速度(由于硬件限制，网络状况等).

如您所想，投票节点确实包含仲裁器.因此，在具有主次仲裁器设置的副本集中，w:majority在以下情况下可能会失败:

As you have imagined, voting nodes does include the arbiter. Thus, in a replica set with primary-secondary-arbiter setup, w:majority could fail in a scenario where:

• 由于某些原因，一个数据承载节点处于脱机状态.
• 该副本集仍处于联机状态，并且具有可写的主副本，因为该拓扑现在已成为primary-arbiter-offline.
• 使用w:1进行的写入将照常成功，但是可以回滚这些写入(因为未将其写入大多数有投票数据的节点).
• 由于仲裁程序不携带任何数据，因此w:majority写入将失败(或无限期等待)，因为仲裁程序被视为表决节点.

• One of the data-bearing node is offline for some reason.
• The replica set is still online with a writable primary, since the topology is now primary-arbiter-offline.
• Writes with w:1 will succeed as usual, but those writes could be rolled back (since it was not written to the majority of voting-data-bearing nodes).
• Since the arbiter carries no data, w:majority writes will fail (or waits indefinitely) since the arbiter is counted as a voting node.

因此，如果您打算在应用程序中使用w:majority，则不建议使用仲裁器.

For this reason, using an arbiter is not recommended if you plan to use w:majority in your application.

请注意，也不建议在分片群集中形成分片的3节点副本集中使用仲裁器，因为块移动需要w:majority.一个分片中有一个承载数据的节点故障将不利于块迁移操作.

Please note that using an arbiter in a 3-node replica set that forms a shard in a sharded cluster is also not recommended, since chunk moves requires w:majority. Having a data-bearing node failure in one shard will be detrimental to chunk migration operations.

这篇关于mongod在哪个版本中的默认写关注是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！