Согласованность записи = ВСЕ: мне все еще нужен еженедельный ремонт, чтобы избежать записей зомби? - PullRequest
0 голосов
/ 30 мая 2018

Насколько я понял, проблема удаления удаленных данных в Cassandra заключается в следующем:

  • Удаление выдается с согласованностью
  • Удалениеуспешно, но некоторые узлы в наборе репликации были недоступны во время удаления
  • Надгробный камень записан во все достигнутые узлы, ничего в других
  • 10 дней прошло, надгробный камень имеет право бытьexpired
  • Уплотнения случаются, надгробия фактически удаляются
  • Выполняется чтение: узлы, получившие ответ на удаление с "нет данных";узлы, которые были недоступны во время удаления ответа со старыми данными;создается зомби

Теперь мой вопрос: если исходное удаление было выполнено с консистенцией = ALL, все узлы либо имели бы надгробную плиту (до истечения срока действия и сжатия), либо вообще не имели бы данных (после истечения срока действия и сжатия),После этого зомби не должны производиться, даже если мы не выполнили ремонт до истечения срока действия надгробной плиты.

Это правильно?

Ответы [ 2 ]

0 голосов
/ 30 мая 2018

Да, вам по-прежнему нужно выполнять ремонт даже с CL.ALL при удалении, если вы хотите гарантировать отсутствие воскрешенных данных.Вы просто уменьшаете вероятность его возникновения, не замечая этого.

Если узел недоступен для удаления, удаление не удастся для клиента (так как cl.all), но все остальные узлы все еще получили удаление.Даже если ваше приложение будет повторять удаление, существует вероятность его сбоя (т. Е. Сервер вашего приложения попал под метеорит).Итак, у вас есть удаление, которое видели 2 из ваших 3 реплик.Если вы понизили значение gc_grace и не выполняли ремонт, другие меры по борьбе с энтропией (подсказки, восстановление при чтении) могут не гарантировать, что надгробный камень (это лучшее усилие, а не гарантия) был замечен 3-м узлом до уплотнения надгробного камня.При следующем чтении затрагивается 3-й узел, в котором есть исходные данные, и не существует надгробной плиты, чтобы сказать, что она была удалена, поэтому вы воскрешаете данные, когда их чтение восстанавливается в других репликах.

Что вы можете сделать, это зарегистрировать оператор где-нибудь, чтобыточка, когда есть тайм-аут cl.all или сбой.Это не гарантия, так как ваше приложение может умереть до записи в журнал, и сбой на самом деле не означает, что запись не достигла всех реплик - просто, что может не записать.Тем не менее, я настоятельно рекомендую использовать только кворум (или local_quorum).Таким образом, вы можете иметь некоторые сбои хоста без потери доступности, так как вам все равно нужен ремонт для гарантии.

0 голосов
/ 30 мая 2018

При выдаче запросов с Consistency = ALL каждый узел, имеющий диапазон маркеров этой конкретной записи, должен подтвердить.Таким образом, если один из узлов не работает во время этого процесса, УДАЛИТЬ не удастся, так как не может достичь требуемой согласованности = ВСЕ.

Таким образом, согласованность = ВСЕ, может в конечном итоге стать сценарием, в котором каждый узел вкластер должен оставаться на месте, иначе запросы не будут выполнены.Вот почему люди рекомендуют использовать менее сильную консистенцию, такую ​​как QUORUM.Таким образом, вы жертвуете высокой доступностью для REPAIRs, если хотите выполнять запросы в CONSISTENCY = ALL

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...