是MongoDB v2.6的WriteConcern"破碎"?

时间:2014-09-17 00:09:15

标签: mongodb replication fault-tolerance

编辑 - 可能重复:To what extent are 'lost data' criticisms still valid of MongoDB? - 如果我刚刚以不同的方式向Google推销某些内容,我或多或少都会回答这个问题。对不起,每个人都是半傻瓜。


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

我的问题特别涉及Emir的第一个问题(Emin Gun Sirer回应MongoDB首席技术官Jared Rosoff对Emin的原始文章的回应,详细描述了MongoDB是如何被破坏的):< / p>

MongoDB坏了(原创): http://hackingdistributed.com/2013/01/29/mongo-ft/

MongoDB被破坏(对Rosoff的回应): http://hackingdistributed.com/2013/02/07/10gen-response/

这些文章的历史可以追溯到一年半前。我一直试图确定MongoDB的WriteConcern是否仍然被破坏(例如,MongoDB仍然不像Emin在问题#1中描述的那样容错,但是看起来围绕这个主题的大多数评论和文章都消失了就在它们出现的时候一样快(就我可以告诉谷歌而言,在2月或5月之后死了沉默)。

我现在明白MongoDB已将默认的WriteConcern设置为ReceiptAcknowledged,但显然这(以及更加一致/容错的选项,Journaled)并不保证写入操作已写入更多的磁盘上比一个节点

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

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

1 个答案:

答案 0 :(得分:2)

是的,您可以将写入问题设置为w = most,以确保应用程序不会考虑写入提交,直到它在单个节点发生故障时持久。以下是相关文档:

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

w = most保证大多数节点已经确认写入,但并不是大多数节点已将其写入磁盘。您还可以保证主节点已将其写入磁盘。

通过三节点副本集的场景,你设置j = 1(在主要节点上记录)和w =多数并等待多数ack,然后再考虑写入是持久的:

  • 如果主节点发生故障并且您收到了确认,则写入是在主磁盘和故障转移上,最远的辅助,也见过您的写入(我们知道大多数人已经看过它),将成为主要的。在故障发生时,辅助设备可能尚未将写入写入磁盘,但很快就会写入磁盘。我们假设只有单个节点发生故障,因此隐含地认为辅助节点不会发生故障。你的写作仍然存在。
  • 如果辅助节点发生故障,则不会进行选举。主要不会发生变化。你的写作仍然存在