Проблема WriteConcern в MongoDB v2.6 не работает?

Редактировать — возможная копия: Что В какой степени критика «потерянных данных» по-прежнему актуальна для MongoDB? — Если бы я просто вбил что-то в Google по-другому, я более или менее получил бы ответ на этот вопрос. Извините за полуобман всех.


Я ненавижу задавать этот вопрос здесь, так как я не уверен на 100%, соответствует ли он правилам этого сайта или нет. Если это не так, я извиняюсь. В настоящее время я собираюсь создать приложение и серьезно рассматривал MongoDB в качестве хранилища данных, пока не наткнулся на две статьи ниже.

Мой вопрос конкретно касается первой проблемы, описанной Эмиром (Эмин Ган Сирер отвечает техническому директору MongoDB на ответ Джареда Розоффа на исходную статью Эмина, в которой подробно описывается, как работает MongoDB):

MongoDB не работает (оригинал): http://hackingdistributed.com/2013/01/29/mongo-ft/

MongoDB не работает (ответ Розоффу): http://hackingdistributed.com/2013/02/07/10gen-response/

Эти статьи датированы добрыми полтора года назад. Я пытался определить, не работает ли MongoDB WriteConcern (например, MongoDB по-прежнему не является отказоустойчивой, как описывает Эмин в выпуске № 1), но, похоже, большинство комментариев и статей, касающихся этой темы, исчезли примерно так же быстро, как они возникли (мёртвая тишина после февраля или мая, насколько я могу судить с помощью Google).

Теперь я понимаю, что MongoDB установила для параметра WriteConcern по умолчанию значение ReceiptAcknowledged, но, по-видимому, это (и еще более последовательный/отказоустойчивый вариант, Journaled) не гарантирует, что операция записи была записана на диск более чем на одном узле. .

Может ли кто-нибудь сказать мне, есть ли теперь в MongoDB параметр WriteConcern, который подтверждает, что операция записи была записана на диск более чем на одном узле?

Заранее спасибо, и еще раз прошу прощения, если задаю вопрос не в том месте.


person KSwift87    schedule 17.09.2014    source источник
comment
Для человека, который проголосовал против, я был бы признателен за комментарий с указанием, почему.   -  person KSwift87    schedule 17.09.2014
comment
Мне кажется нормальный вопрос. Глядя на столько плохо написанного, я не понимаю, почему это плохо. +1   -  person Salvador Dali    schedule 17.09.2014
comment
Спасибо, Сальвадор. Я отредактировал заголовок, поместив Broken в двойные кавычки, так как подумал, что, возможно, это кого-то расстроило. Однако, если бы указанный человек действительно прочитал мой вопрос, они бы увидели, что Сломанный конкретно относится к статьям Эмина Сирера, где он объясняет, что он имеет в виду под сломанным.   -  person KSwift87    schedule 17.09.2014


Ответы (1)


Да, вы можете установить для параметра записи значение w=majority, чтобы приложение не считало запись зафиксированной до тех пор, пока она не станет надежной в случае сбоя одного узла. Вот соответствующая документация:

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

w=majority гарантирует, что большинство узлов подтвердили запись, но не то, что большинство записало ее на диск. Вы также можете гарантировать, что первичный узел записал его на диск.

Проходим сценарий с набором реплик из трех узлов, где вы устанавливаете j=1 (журналируется на первичном) и w=majority и ждете подтверждения большинства, прежде чем рассматривать запись как постоянную:

  • Если первичный узел выйдет из строя и вы получили подтверждение, запись будет на первичный диск, а при аварийном переключении самый дальний передний вторичный узел, который также видел вашу запись (мы знаем, что большинство ее видели), станет первичным. Вторичный, возможно, еще не записал запись на диск в момент сбоя, но скоро это сделает. Мы предполагали отказ только одного узла, поэтому неявно предполагали, что вторичный узел не выходит из строя. Ваша запись сохраняется.
  • Если вторичный узел выйдет из строя, выборы не произойдут. Первичка не изменится. Ваша запись сохраняется
person erlichson    schedule 17.09.2014
comment
Благодарю за ваш ответ. Тем не менее, я чувствую, что следующая ссылка подтверждает мое беспокойство по поводу того, что проблема записи в журнале, даже в наборах реплик, гарантирует запись только на первичный; ни одно из второстепенных. Я думаю, это то, о чем говорил Эмин в своих сообщениях в блоге. docs.mongodb.org/manual/core/write-concern / - person KSwift87; 17.09.2014
comment
Я отредактировал свой ответ, чтобы дополнительно объяснить, что произойдет в случае сбоя одного узла и w = большинства. Используете ли вы ведение журнала или нет, на самом деле не важно в этом сценарии. Если вы предполагаете, что произошел сбой только одного узла, ваша запись будет сохраняться, даже если ведение журнала не включено. - person erlichson; 17.09.2014