Как управлять сбоем узла с помощью фактора репликации Cassandra 1?
У меня есть кластер Cassandra (DSE) с тремя узлами, где меня не волнует потеря данных, поэтому я установил свой RF на 1. Мне было интересно, как Cassandra будет реагировать на запросы на чтение / запись, если узел выйдет из строя (у меня CL= ВСЕ в моих запросах прямо сейчас).
В идеале я хотел бы, чтобы эти запросы выполнялись успешно, если данные существуют - только на оставшихся доступных узлах, пока я не заменю мертвый узел. Это пространство ключей по сути очень большой кеш; Я могу заменить любые данные в случае потери.
1 ответ
(Отказ от ответственности: я сотрудник ScyllaDB)
Предполагая, что ваш ключ раздела был достаточно уникальным, при использовании RF=1 каждый из ваших 3 узлов содержит 1/3 ваших данных. Кстати, в этом случае CL =ONE/ALL в основном совпадает с тем, что для ваших данных есть только 1 реплика и нет высокой доступности (HA).
Запросы на "существующие" данные от 2-х узлов будут выполнены успешно. Тем не менее, когда один из 3 узлов не работает, 1/3 ваших клиентских запросов (для существующих данных) не будет выполнена, так как в основном 1/3 ваших данных недоступна, пока не выйдет неработающий узел (обратите внимание, что nodetool repair не имеет значения при использовании RF=1), поэтому я думаю, что восстановление из моментального снимка (если он у вас есть) является единственным вариантом.
Пока узел не работает, после выполнения nodetool decommissionдиапазоны токенов будут перераспределены между двумя верхними узлами, но это будет применяться только для новых операций записи и чтения.
Вы можете прочитать больше об архитектуре кольца здесь: http://docs.scylladb.com/architecture/ringarchitecture/