MongoDB v2.6 的 WriteConcern 是否“损坏”？答案

【问题标题】：Is MongoDB v2.6's WriteConcern "Broken"?MongoDB v2.6 的 WriteConcern 是否“损坏”？
【发布时间】：2014-09-17 00:09:14
【问题描述】：

编辑 - 可能重复：To what extent are 'lost data' criticisms still valid of MongoDB? - 如果我只是以不同的方式向 Google 打了一些东西，我或多或少会回答这个问题。很抱歉让大家误会了。

我讨厌在这里问这个问题，因为我不能 100% 确定它是否符合本网站的指南。如果没有，我道歉。目前我正在寻找构建一个应用程序并认真考虑将 MongoDB 作为数据存储，直到我遇到以下两篇文章。

我的问题与 Emir 首次描述的问题（Emin Gun Sirer 回应 MongoDB 首席技术官 Jared Rosoff 对 Emin 详细说明 MongoDB 如何被破坏的原始文章的回应）有关：

MongoDB 坏了（原创）： http://hackingdistributed.com/2013/01/29/mongo-ft/

MongoDB 已损坏（对 Rosoff 的回应）： http://hackingdistributed.com/2013/02/07/10gen-response/

这些文章的日期是一年半以前。我一直在尝试确定 MongoDB 的 WriteConcern 是否仍然损坏（例如，MongoDB 仍然不是 Emin 在问题 #1 中描述的容错方式），但似乎大多数围绕该主题的 cmets 和文章很快就消失了他们突然出现（据我在 Google 上得知，2 月或 5 月之后一片死寂）。

我现在明白 MongoDB 已将默认 WriteConcern 设置为 ReceiptAcknowledged，但显然这（以及更一致/容错的选项，Journaled）并不能保证写入操作已写入磁盘更多超过一个节点。

有人可以告诉我 MongoDB 现在是否有一个 WriteConcern 设置来确认写入操作已写入多个节点上的磁盘？

提前谢谢，如果我在错误的地方问这个问题，我再次道歉。

【问题讨论】：

对于投反对票的人，我希望能发表评论说明原因。
对我来说似乎是一个正常的问题。看了这么多写得不好的，我不明白为什么不好。 +1
谢谢萨尔瓦多。我编辑了标题以将 Broken 放在双引号中，因为我认为这可能是有人不高兴的原因。如果上述个人确实阅读了我的问题，他们会看到“破碎”是专门指 Emin Sirer 的文章，他在其中解释了“破碎”的含义。

标签： mongodb replication fault-tolerance

【解决方案1】：

是的，您可以将写入关注度设置为 w=majority，以确保应用程序不会考虑写入已提交，直到它在面对单个节点故障时能够持久。以下是相关文档：

http://docs.mongodb.org/manual/core/replica-set-write-concern/

w=majority 保证大多数节点已确认写入，但不保证大多数节点已将其写入磁盘。您还可以保证主节点已将其写入磁盘。

通过一个三节点副本集的场景，您设置 j=1（在主节点上记录）和 w=majority，并在考虑写入持久性之前等待多数确认：

如果主节点出现故障并且您收到了确认，则写入在主节点的磁盘上，并且在故障转移时，也看到您的写入（我们知道大多数人已经看到）的最靠前的辅助节点将成为主节点。在发生故障时，辅助节点可能尚未将写入写入磁盘，但很快就会写入。我们假设只有单个节点故障，因此隐含地假设辅助节点没有故障。您的写入仍然存在。
如果辅助节点发生故障，将不会进行选举。主要不会改变。您的写入仍然存在

【讨论】：

感谢您的回复。但是，我觉得下面的链接支持了我对 Journaled 的写入关注点的担忧，即使在副本集中，也只能保证对主节点的写入；不是任何次级。我认为这就是 Emin 在他的博客文章中所说的。 docs.mongodb.org/manual/core/write-concern/…
我编辑了我的回复，以进一步解释在单节点故障和 w=majority 的情况下会发生什么。在那种情况下，您是否使用日记功能实际上并不重要。如果您假设只有单节点故障，那么即使未启用日志记录，您的写入也会持续存在。