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

Question

我在mongodb的文档中找不到默认的写入问题以及如何定义“已确认的写入”。似乎在不同的mongodb版本中这已经改变，例如v3.2文档所示：

在3.2.6之前的3.2版本中，w：“多数”表示j：如果启用日记功能，则为true。对于早期版本的MongoDB，“ w：大多数”并不意味着日记。

要么：

在版本3.0中进行了更改：在MongoDB 3.0之前，w：“多数”是指副本集成员的大多数。

要么：

在2.6版中进行了更改：在主/从部署中，MongoDB将w：“多数”等同于w：1.在MongoDB的早期版本中，w：“多数”在主/从部署中产生错误。

另外，我想知道“多数”是指v3.2文档中的所有投票节点：

请求确认写入操作已传播到大多数投票节点[1]，包括主要节点。

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

Answer 1

MongoDB中的默认写入问题可w:1追溯到2012年的MongoDB 2.2。

您可以使用三种不同的设置来设置当前MongoDB版本（3.2.6及更高版本）中的写关注：

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

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

这里的特殊设置是w:majority。这意味着写操作必须传播到要确认的副本集中的大多数投票节点（以及它们的日记）。在提供良好性能的同时，可以说这是最安全的设置，因为：

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

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

• 由于某些原因，一个数据承载节点处于脱机状态。
• 副本集仍在线且可写主副本处于联机状态，这是因为拓扑现在是主仲裁者离线的。
• 与的写入w:1将照常成功，但是可以回滚这些写入（因为未将其写入大多数有投票数据的节点）。
• 由于仲裁器不携带数据，因此w:majority写入将失败（或无限期等待），因为仲裁器被视为投票节点。

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

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