Тайм-аут драйвера Cassandra nodejs после перемещения узла

Question

Мы используем vnodes на нашем кластере.

Я заметил, что, когда пространство токенов узла изменяется (автоматически на vnodes, во время восстановления или очистки после добавления новых узлов), драйвер datastax nodejs получает много "Операция истекла - получил только X ответов" в течение нескольких минут,

Я попытался использовать ONE и LOCAL_QUORUM.

Я полагаю, это связано с тем, что координатор не попал в нужный узел сразу после перемещения. Это кажется логичным поведением (данные были перемещены), но мы действительно хотим решить эту конкретную проблему.

Что вы, ребята, предлагаете нам сделать, чтобы избежать этого? Наличие пользовательской политики повторных попыток? Кеширование? Меняется последовательность?

Пример поведения

когда мы видим это:

4/7/2016, 10:43am   Info    Host 172.31.34.155 moved from '8185241953623605265' to '-1108852503760494577'

Мы видим всплеск этих:

{
  "message":"Operation timed out - received only 0 responses.",
  "info":"Represents an error message from the server",
  "code":4608,
  "consistencies":1,
  "received":0,
  "blockFor":1,
  "isDataPresent":0,
  "coordinator":"172.31.34.155:9042",
  "query":"SELECT foo FROM foo_bar LIMIT 10"
}

Answer 1

Я полагаю, это связано с тем, что координатор не попал в нужный узел сразу после перемещения. Это кажется логичным поведением (данные были перемещены), но мы действительно хотим решить эту конкретную проблему.

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

Если вы можете воспроизвести эту ошибку, активируйте трассировку запросов, чтобы сузить проблему.

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