Почему Кассандра не может пережить потерю ни одного узла без потери данных. с коэффициентом репликации 2
Привет, я пробовал разные конфигурации, используя сайт https://www.ecyrd.com/cassandracalculator/
Но я не мог понять следующие результаты, показанные для конфигурации
Cluster size 3
Replication Factor 2
Write Level 1
Read Level 1
Вы можете пережить потерю без узлов без потери данных.
Для справки я видел вопрос о потере узла Кассандрой
Но это все равно не помогает понять, почему уровень записи 1 с репликацией 2 заставил бы мой кластер кассандры не пережить потерю ни одного узла без потери данных?
Запрос на запись отправляется на все узлы реплики, и даже если 1 ответит назад, он успешен, поэтому, если 1 узел не работает, все запросы на запись будут переданы на другой узел реплики и вернутся успешно. Это будет в конечном итоге последовательным.
Может кто-нибудь помочь мне разобраться с примером.
3 ответа
Я думаю, что калькулятор работает в худшем случае.
Вы можете пережить потерю одного узла, если ваши данные будут избыточно доступны на двух из трех узлов. Дело в том, что уровень записи ONE заключается в том, что нет никакой гарантии, что данные действительно присутствуют на двух узлах сразу после подтверждения вашей записи.
Давайте предположим, что координатор вашей записи - это один из узлов, содержащих копию записи, которую вы пишете. На уровне записи ONE вы говорите кластеру подтвердить вашу запись, как только запись будет зафиксирована на одном из двух узлов, которые должны содержать данные. Координатор может сделать это еще до того, как попытаться связаться с другим узлом (чтобы увеличить задержку, воспринимаемую клиентом). Если в этот момент, сразу после подтверждения записи, но перед попыткой связаться со вторым узлом, узел-координатор выходит из строя и не может быть возвращен, то вы потеряли эту запись и данные с ней.
Это так, потому что уровень записи равен 1. И если ваше приложение пишет только на 1 узле (и ожидает данных, чтобы в итоге получить согласованность / синхронизацию, что займет ненулевое время), тогда данные могут быть потеряны, если что один сервер потерян прежде, чем произойдет синхронизация
Когда вы читаете или записываете данные, Cassandra вычисляет хеш-токен для данных и распределяет их по соответствующим узлам. Если у вас кластер из 3 узлов с коэффициентом репликации 2, значит, ваши данные хранятся в 2 узлах. Таким образом, в момент, когда 2 узла не работают, который отвечает за токен A, и этот токен не является частью узла 3, в конечном счете, даже если у вас есть один узел, у вас все равно будет TokenRangeOfflineException.
Дело в том, что нам нужны реплики (токены), а не узлы. Также см. Аналогичный вопрос ответил здесь.