Из-за этой мелочи мы называем «данные».
В проблеме не упоминается конкретное c количество узлов, которые вышли из строя, или коэффициент репликации (RF), с которым определены пространства ключей . Из-за этого у вас нет никаких гарантий относительно определенных диапазонов токенов c (и их реплик), которые также могут быть недоступны. Когда, по всей вероятности, в этом случае не работают полные наборы реплик данных.
самая большая группа все еще может сбросить себя
I думаю I знайте, что вы здесь имеете в виду. Когда узлы списываются или удаляются, оставшиеся узлы корректируют назначения своих диапазонов токенов, чтобы обеспечить 100% охват данных. Это правда. Однако данные , , связанные с этими диапазонами, не перемещаются вместе с ними автоматически.
Этого не происходит, пока не будет запущена операция восстановления. И если несколько узлов не работают (опять же), включая полные наборы реплик данных, у вас может не быть узлов, которые вам нужны для потоковой передачи некоторых данных.
Пример:
Допустим, у нас есть кластер из 12 узлов (в одном D C), пространства ключей определены с RF = 3, и узлы «разбиваются» на группы по 2 (группа A), 3 (группа B) и 7 (группа C).
Если группа C все еще обслуживает запросы, будут некоторые разделы данных, которые изначально:
- Имели все реплики в группе C. Эти запросы по-прежнему будут успешными.
- Была 1 реплика в группе A или B. Эти запросы по-прежнему будут успешными @
QUORUM или меньше, но теперь не будут выполнены на ALL. - Было 2 реплики в группах A или B (или в обеих). Эти запросы по-прежнему будут успешными @
ONE, но теперь не будут выполняться на всех других уровнях согласованности. - Если бы все данные были на узлах в обеих группах A и B. Все запросы для этих разделов завершатся ошибкой.
- Имеются все данные об узлах в группе B. Все запросы для этих разделов завершатся ошибкой.