Почему cassandra не может пережить потерю узлов без потери данных. с фактором репликации 2

Привет, я пробовал другую конфигурацию, используя сайт https://www.ecyrd.com/cassandracalculator/

Но я не мог понять следующие результаты, показанные для конфигурации

Cluster size  3
Replication Factor  2
Write Level 1   
Read Level 1

Вы можете пережить потерю узлов без потери данных.

Для справки я видел вопрос Cassandra потеря узла

Но это все еще не помогает понять, почему уровень записи 1 с репликацией 2 заставит мой кластер cassandra не пережить потерю узла без потери данных?

Запрос на запись отправляется на все узлы реплики, и даже если 1 ответит обратно, это будет успешным, поэтому, если 1 узел не работает, все запросы на запись перейдут на другой узел реплики и вернут успех. В конце концов, это будет последовательно.

Может кто-нибудь помочь мне понять на примере.


cassandra replication consistency eventual-consistency cassandra-3.0
person Hiteshdua1    schedule 22.08.2017    source источник

Ответы (3)


arrow_upward
3
arrow_downward

Я предполагаю, что калькулятор работает с худшим сценарием.

Вы можете пережить потерю одного узла, если ваши данные избыточно доступны на двух из трех узлов. Проблема с уровнем записи ONE заключается в том, что нет никакой гарантии, что данные действительно присутствуют на двух узлах сразу после того, как ваша запись была подтверждена.

Предположим, что координатор вашей записи — это один из узлов, хранящих копию записи, которую вы записываете. С уровнем записи ONE вы говорите кластеру подтвердить вашу запись, как только запись будет зафиксирована на одном из двух узлов, которые должны хранить данные. Координатор может сделать это еще до того, как попытается связаться с другим узлом (чтобы увеличить задержку, воспринимаемую клиентом). Если в этот момент, сразу после подтверждения записи, но до попытки связаться со вторым узлом, узел-координатор выходит из строя и не может быть восстановлен, то вы потеряли эту запись и данные с ней.

person Ralf    schedule 22.08.2017
comment
Можете ли вы просто подтвердить мое понимание? Ниже приведен наихудший сценарий: 1. Cassandra получает запрос на запись и отправляет его на все узлы-реплики. 2. Успешный запрос на запись подтверждается одним узлом (уровень согласованности ONE), а затем Cassandra подтверждает запрос на запись. 3. Другая реплика (которая также получила запрос на запись, но не подтвердила его, поскольку в тот раз каким-то образом не удалось записать эти данные. 4. Исходный узел, подтвердивший запрос, выходит из строя. Можете ли вы помочь мне определить сценарии для случая 3, если мой понимание правильное - person Hiteshdua1; 22.08.2017
comment
@ Hiteshdua1, я обновил свой ответ, чтобы он был более конкретным и учитывал координатора. - person Ralf; 22.08.2017
comment
Это верно - калькулятор работает с наихудшим сценарием, и объяснение Ральфа верно. - person Janne Jalkanen; 14.11.2017

arrow_upward
0
arrow_downward

Когда вы читаете или записываете данные, Cassandra вычисляет хеш-токен для данных и распределяет их по соответствующим узлам. Когда у вас есть кластер из 3 узлов с коэффициентом репликации 2, это означает, что ваши данные хранятся на 2 узлах. Таким образом, в момент, когда 2 узла не работают, которые отвечают за токен A, и этот токен не является частью узла 3, в конечном итоге даже у вас есть один узел, у вас все равно будет TokenRangeOfflineException.

Дело в том, что нам нужны реплики (токены), а не узлы. Также см. Ответ на аналогичный вопрос здесь.

person Shoban Sundar    schedule 22.08.2017
comment
Итак, мой вопрос в том, правильно ли утверждение. Вы можете пережить потерю узлов без потери данных. Я считаю, что я могу пережить потерю 1 узла данных в вышеупомянутом сценарии. - person Hiteshdua1; 22.08.2017
comment
Это зависит от хешированного токена. Если ваш хешированный токен доступен в выжившем узле, он будет успешным, иначе он потерпит неудачу. - person Shoban Sundar; 22.08.2017
comment
Разве фактор репликации не сделает доступным хотя бы 1 узел с этим хешированным токеном? Я что-то упускаю здесь. Я считаю, что 1 отдельный запрос на запись направляется узлу-координатору, который всегда отправляет его на все узлы-реплики, и даже когда 1 узел не работает, у меня все еще есть запись как успешная, поэтому я считаю, что могу пережить потерю 1 узла без потери данных. - person Hiteshdua1; 22.08.2017
comment
Каждый узел в кластере Cassandra будет иметь диапазон токенов, который вы можете увидеть в кольце/статусе nodetool. Например. у вас есть узлы 1, 2, 3 с токенами A, B и C соответственно. Когда узел-координатор (скажем, узел 1) получает данные, они хэшируются, и вычисляется токен, скажем, B. Таким образом, узел-координатор попытается записать в узел 2 (который владеет токеном B), за которым следует узел 3 (циклический порядок). Если узлы 2 и 3 (владеющие токенами B и C) не работают, то очевидно, что ваш узел, отвечающий за токен, недоступен, и, следовательно, ваша операция не выполняется. Вы должны понимать вычисление токенов и их назначение узлам. - person Shoban Sundar; 22.08.2017

arrow_upward
0
arrow_downward

Это так, потому что уровень записи равен 1. И если ваше приложение записывает только на 1 узел (и ожидает, что данные будут в конечном итоге согласованы/синхронизированы, что займет ненулевое время), то данные могут быть потеряны, если что один сервер сам теряется до того, как может произойти синхронизация

person r005t3r    schedule 22.08.2017
comment
Но Cassandra всегда отправляет запрос на запись всем узлам-репликам, независимо от уровня согласованности. Ниже приведен наихудший сценарий: 1. Cassandra получает запрос на запись, отправляет его на все узлы-реплики 2. Успешный запрос на запись подтверждается одним узлом (уровень согласованности ONE), а затем Cassandra подтверждает запрос на запись. 3. Другая реплика (которая также получила запрос на запись, но не подтвердила его, поскольку в тот раз она каким-то образом не смогла записать эти данные. (Может быть полезно, если бы вы могли объяснить какие-либо сценарии на этом?) 4. Исходный узел, подтверждающий это, идет вниз. - person Hiteshdua1; 22.08.2017
comment
Я думаю, вы знаете худший сценарий. Теперь вопрос, как может случиться пункт 3? Одна из причин, о которой я могу думать, - это сценарий перегрузки (когда узел занят обработкой другого запроса и не может развлечь нескольких). В этом случае запрос на запись будет отправлен на него. Хотя подсказка может быть сохранена на узле-координаторе, в худшем случае она также превысит max_hint_window_in_ms. - person r005t3r; 22.08.2017