Понимание Hinted Handoffs и репликации данных в Cassandra

У нас есть кластер Cassandra из 3 узлов с RF = 2. Согласованность чтения и записи установлена ​​на ONE. Мы также используем Vnodes. Обозначим эти узлы как N1, N2 и N3. Допустим, N3 выходит из строя. У меня сложилось впечатление, что всякий раз, когда узел выходит из строя, другие узлы будут хранить подсказки, а всякий раз, когда появляется N3, подсказки будут отправляться на N3, тем самым обеспечивая согласованность данных между репликами. Однако, просматривая документы, я наткнулся на параметр max_hint_window_in_ms, который по умолчанию равен 3 часам. Таким образом, если узел мертв более 3 часов, он считается мертвым навсегда, и подсказки не сохраняются. Все идет нормально.

Итак, теперь я понимаю, что если узел не работает, скажем, 10 часов, то подсказки за первые 3 часа будут переданы этому узлу, когда он вернется, но записи для этой 7-часовой продолжительности будут потеряны для этого узел. Более того, если запрос на чтение запускается для определенного диапазона токенов, и поскольку этот узел также имеет право обслуживать запросы на чтение для диапазона токенов, он вернет null вместо фактических данных, которые хранятся в каком-то другом узле. Правильно ли я понимаю? Что же тогда делать?


person Ranjeet Ranjan    schedule 30.05.2017    source источник
comment
Это тестируется, и поведение неожиданно? Или вы ищете ожидаемое поведение, если сценарий должен был произойти? Поскольку уровень согласованности установлен на ОДИН, все операции чтения/записи должны быть успешными (при условии, что пропускная способность невелика).   -  person daniel    schedule 30.05.2017
comment
Я пытаюсь оценить, каким будет поведение, если один из моих узлов выйдет из строя на период более 3 часов (значение по умолчанию max_hint_window_in_ms).   -  person Ankush92    schedule 30.05.2017


Ответы (1)


Что же тогда делать?

В документах говорится, что когда вы вернете неисправный узел (N3), вам придется выполнить его ремонт.

Честно говоря, в большинстве наших кластеров мне проще просто удалить узел (пока он не работает), а затем повторно загрузить его в кластер. Обычно это происходит быстрее, чем вычисление деревьев Меркла и потоковая передача данных о ремонте. Но если у вас не так много данных на узел (скажем, менее 20 ГБ), выполнение восстановления не должно быть слишком болезненным.

person Aaron    schedule 30.05.2017
comment
Мне кажется, ты прав. У нас есть около 100 ГБ данных на узел, которые растут со скоростью около 5-10 ГБ в день. Ремонт довольно болезненный. Приходится оставлять их на ночь. Но поскольку хинтованные передачи являются частью процесса восстановления и сохраняются только в течение 3-часового периода (значение по умолчанию), не будут ли мы по-прежнему терять данные за период после 3 часов, даже после выполнения исправления? - person Ankush92; 30.05.2017
comment
@ Ankush92 Нет, ваш RF = 2 гарантирует, что будет записана хотя бы одна реплика. При восстановлении/загрузке целевой узел будет использовать эту реплику для потоковой передачи данных. - person Aaron; 30.05.2017