Как восстановить узел Cassandra после неудачной загрузки

Узел не работает во время начальной загрузки нового узла, и загрузка не удалась. Узел закрылся, оставив в журнале следующие сообщения:

INFO  [main] 2015-02-07 06:03:32,761 StorageService.java:1025 - JOINING: Starting to bootstrap...
ERROR [main] 2015-02-07 06:03:32,799 CassandraDaemon.java:465 - Exception encountered during startup
java.lang.RuntimeException: A node required to move the data consistently is down (/10.0.3.56).  If you wish to move the data from a potentially inconsistent replica, restart the node with -Dcassandra.consistent.rangemovement=false

Как восстановить ситуацию? Могу ли я перезапустить процесс начальной загрузки после того, как отказавший узел снова подключится к сети? Или мне нужно отменить частичную загрузку и как-то попробовать еще раз?

Я отследил первопричину. Новый узел смог подключиться к узлу 10.0.3.56, но 10.0.3.56 не смог открыть обратное соединение с новым узлом. 10.0.3.56 содержал единственную копию некоторых данных, которые нужно было перенести на новый узел (коэффициент репликации == 1), но его попытки отправить данные были заблокированы.


cassandra cluster-computing bootstrapping
person stub    schedule 06.02.2015    source источник
comment
Вы пытаетесь заменить мертвый узел?   -  person Roman Tumaykin    schedule 07.02.2015
comment
Нет, это было добавление нового узла. Одно из существующих пространств ключей использовало коэффициент репликации, равный 1, и один из узлов, содержащих единственную копию данных, которую необходимо переместить на новый узел, был недоступен.   -  person stub    schedule 07.02.2015

Ответы (1)


arrow_upward
4
arrow_downward

Поскольку это включает в себя перемещение данных, а не только репликацию, и в зависимости от места в коде, где выдается исключение, я предполагаю, что вы пытаетесь заменить мертвый узел, как это описано здесь: http://www.datastax.com/documentation/cassandra/2.0/cassandra/operations/ops_replace_node_t.html

Судя по всему, узел не дошел до присоединения к кольцу. Вы можете перепроверить, запустив nodetool status, если узел вообще присоединился.

Если нет, то вы можете просто удалить все из данных, журнала коммитов и сохраненных кешей и перезапустить процесс. Что не так с этим узлом 10.0.2.56?

Если этот узел присоединился к кольцу, то все равно будет безопасно просто перезапустить его после запуска узла 10.0.2.56.

person Roman Tumaykin    schedule 07.02.2015
comment
Это новый узел, добавляемый в кластер. Системное пространство ключей было удалено с диска, и служба начала указывать на живое и доступное для связи начальное число. - person stub; 07.02.2015
comment
Присмотревшись к моим журналам, я не думаю, что с узлом .56 когда-либо можно было связаться (или, если это было для начала, брандмауэр отключил доступ во время процесса). - person stub; 07.02.2015
comment
Узлу удалось присоединиться к кольцу. «статус узла» из семени показал его как UN и содержит свою часть пространства ключей system_auth, и я вижу эти данные на диске. - person stub; 07.02.2015
comment
В этом случае вы можете просто перезапустить узел. - person Roman Tumaykin; 08.02.2015
comment
Я сталкиваюсь с этой проблемой, когда раскручиваю новое кольцо Кассандры. Некоторые узлы могут не присоединиться к кольцу и выдать эту ошибку. Да, я могу перезапустить службу, и она заработает, но есть ли способ обойти это поведение? - person Sean Glover; 27.05.2016