разница Cassandra между ЛЮБЫМИ и ONE непротиворечивости уровнями

Question

Предположения: RF = 3

В некоторых видео в Интернете о динамике уровня согласованности говорит, что CL = ONE лучше тогда CL = ANY, потому что, когда мы используем CL = ANY координатор будет будьте рады сохранить только подсказку (и данные) (мы предполагаем, что все остальные узлы с соответствующими диапазонами ключей разделов), и мы можем потерять наши данные из-за сбоя координатора. Но подождите минутку ... как я понимаю, если мы использовали CL = ONE и, например, у нас был только один (из трех) доступных узлов для этого ключа раздела, у нас был бы только один узел со вставленными данными. Опасность потери одинакова.

Но я думаю, что мы должны принимать равные ситуации - все узлы для конкретного токена исчезли. Тогда лучше отказаться от операции записи, а затем написать с таким большим риском потери координатора.

Answer 1

CL = ANY, вероятно, никогда не должно использоваться на производственном сервере. Записи будут недоступны, пока подсказка не будет записана на узел, владеющий этим разделом, потому что вы не можете читать данные, когда они находятся в журнале подсказок.

Использование CL = ONE и RF = 3 с двумя узлами вниз, вы должны иметь данные, хранящиеся как в: a) журнале фиксации и памяти на узле, и b) журнале подсказок. Вероятно, это разные узлы, но они могут быть одинаковыми на 1/3 времени. Итак, да, с CL = ONE и CL = ANY вы рискуете полностью потерять данные с отказом одного узла.

Вместо ЛЮБОГО или ОДНОГО, используйте CL = QUORUM или CL = LOCAL_QUORUM.

Answer 2

Дело в том, что подсказки будут храниться в течение 3 часов по умолчанию и в течение более длительного времени, чем при выполнении ремонта. Вы можете восстановить, если у вас есть хотя бы одна копия этих данных на одном узле где-то в кластере (подсказки, которые хранятся на координаторе, не учитываются).

Consistency One гарантирует, что хотя бы один узел в кластере имеет его в журнале фиксации независимо от того, что. Любой в худшем случае хранится в подсказках координатора (другие узлы не могут получить к нему доступ), и это сохраняется по умолчанию в течение 3 часов. По прошествии 3 часов с помощью ANY вы теряете данные, если другие два экземпляра не работают.

Если вы беспокоитесь об опасности, используйте кворум, а 2 узла должны будут гарантировать сохранение данных. Это решение разработчика/дизайнера приложений. Кворум обычно будет иметь немного большие задержки при записи, чем один. Но вы всегда можете добавить больше узлов и т. Д., Если нагрузка резко возрастет.

также посмотреть на этом хорошем инструменте, чтобы увидеть, какое влияние делать различную консистенцию и факторы репликации имеют в приложениях:

https://www.ecyrd.com/cassandracalculator/

С РФ 3, 3 узлов в кластере будет на самом деле получить запись. Согласованность - это только то, как долго вы хотите дождаться ответа от них ... Если вы используете One, вы будете ждать, пока один узел получит его в журнале фиксации. Но координатор на самом деле отправит записи всем 3. Если они не отвечают, координатор сохранит записи в подсказки.

В большинстве случаев любая в производстве - плохая идея.