哪个版本的默认mongod编写关注点是什么？

Question

我在mongodb's documentation中找不到默认的写入问题以及如何定义“已确认的写入”。 似乎在不同的mongodb版本中，情况都发生了变化，例如v3.2 documentation所示：

  

在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 documentation中的所有投票节点：

  

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

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

Answer 1

早在2012年，MongoDB的默认写入问题就是w:1。

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

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

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

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

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

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

• 由于某些原因，一个数据承载节点处于脱机状态。
• 副本集仍处于联机状态，且主目录可写，因为拓扑现在是primary-arbiter-offline。
• 使用w:1进行的写入将照常成功，但是这些写入可以回滚（因为它没有写入大多数有投票数据的节点）。
• 由于仲裁器不携带任何数据，因此w:majority写入将失败（或无限期等待），因为仲裁器被视为投票节点。

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

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