Ошибка Cassandra: нет узлов, присутствующих в кластере

Я просто пытаюсь изучить Cassnadra, я делаю простое упражнение по установке двух кластеров узлов, но у меня есть трудности - до сих пор он работал. Cassandra Версия: 2.1.1.Ошибка Cassandra: нет узлов, присутствующих в кластере

Хост ОС: Centos 6.5 64-битный

Java: 8 (Oracle)

Количество узлов: 2

Узел адреса: 192.168.0.41 и 192.168.0.43 (Статическое)

открытых портов на брандмауэрах на обоих полях: 7000, 9042, 9160, 7199

Я сделал следующее для настройки кластера:

Измененное cluster_name на обоих полях, чтобы "MyCluster", как в cassandra.yaml и в таблицах, как описано здесь:

cassandra - Saved cluster name Test Cluster != configured name

Измененное listen_address к 192.168.0.41 и 192.168.0.43 respectivelly.

Изменен rpc_address до 192.168.0.41 и 192.168.0.43.

На 41 я поставил "семена: 192.168.0.43"

На 43 я поставил "семена: 192.168.0.43" (так же, как и на 41)

Каждый узел работает сам по себе (когда другой вниз), он начинает и реагирует на

nodetool status

просто отлично, и продолжать работать, я могу также соединиться с cqlsh и запустить

describe keyspaces;

Это тоже работает. Но когда я запускаю оба узла одновременно, один из них умирает через минуту или две.

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

error: No nodes present in the cluster. Has this node finished starting up? 
-- StackTrace -- 
java.lang.RuntimeException: No nodes present in the cluster. Has this node finished starting up? 
    at org.apache.cassandra.dht.Murmur3Partitioner.describeOwnership 
     (Murmur3Partitioner.java:130) 
     ....

другой узел продолжает работать нормально, и он сохраняет отчетность о 100% -ном владении сам по себе как единственный узел в кластере.

Вот system.log часть 43 вокруг времени "умер":

WARN [GossipStage:1] 2014-11-17 04:33:30,163 TokenMetadata.java:198 - Token -7592767110844961279 changing ownership from /192.168.0.43 to /192.168.0.41 
WARN [GossipStage:1] 2014-11-17 04:33:30,163 TokenMetadata.java:198 - Token -7240492143116021720 changing ownership from /192.168.0.43 to /192.168.0.41 
WARN [GossipStage:1] 2014-11-17 04:33:30,163 TokenMetadata.java:198 - Token -8434936427655644773 changing ownership from /192.168.0.43 to /192.168.0.41 
WARN [GossipStage:1] 2014-11-17 04:33:30,163 TokenMetadata.java:198 - Token -1656745619022636889 changing ownership from /192.168.0.43 to /192.168.0.41 
WARN [GossipStage:1] 2014-11-17 04:33:30,163 TokenMetadata.java:198 - Token -7470625165291146007 changing ownership from /192.168.0.43 to /192.168.0.41 
INFO [HANDSHAKE-/192.168.0.41] 2014-11-17 04:33:30,230 OutboundTcpConnection.java:427 - Handshaking version with /192.168.0.41 
INFO [GossipTasks:1] 2014-11-17 04:33:49,179 Gossiper.java:906 - InetAddress /192.168.0.41 is now DOWN 
INFO [HANDSHAKE-/192.168.0.41] 2014-11-17 04:33:50,190 OutboundTcpConnection.java:427 - Handshaking version with /192.168.0.41 
INFO [SharedPool-Worker-1] 2014-11-17 04:34:30,224 Gossiper.java:892 - InetAddress /192.168.0.41 is now UP 
INFO [CompactionExecutor:5] 2014-11-17 04:41:01,178 CompactionManager.java:521 - No files to compact for user defined compaction 
INFO [CompactionExecutor:6] 2014-11-17 04:51:01,187 CompactionManager.java:521 - No files to compact for user defined compaction

Любая идея, что может быть не так? Спасибо

источник

2014-11-17 henry

Наблюдение после ряда экспериментов, начальный узел был тем, который «умирает» независимо от того, какой порядок. – henry

Вы нашли решение, у меня такая же проблема? –

Кажется, что ваша конфигурация верна. Давайте попробуем следующее:

Start 43 первого (узел семян)

После 43 заканчивается запуск, запуск 41.

источник

2014-11-17 07:33:16 Rocherlee

Запуск 43. Убедитесь, что он работает и отвечает. Ожидание 2 минуты. Проверено 43 снова - все хорошо. Начато 41. Убедилось, что он работает и отвечает. Примерно через 15 секунд 43 раз он был мертв с симптомами, описанными выше. 41 продолжал работать как единственный узел в кластере – henry

@henry вы также можете проверить (и опубликовать соответствующие части) конец /var/log/cassandra/system.log? Это должно дать больше информации о том, почему узел 43 имеет проблемы. – BrianC

@brian, часть журнала добавлена - спасибо – henry

Я не уверен, что reccursive семя хорошо.Попробуйте удалить семена на 43 «Я установил» семена: 192.168.0.43 «».

источник

2014-11-18 07:54:28

Но они не являются рекуперативными: и 41, и 43 указывают на 43 – henry

Я пытался установить семена для 43 ни к чему - та же проблема – henry

Я также новичок в Cassandra, и я встретил точно такую же ошибку, как вы описали выше.

Моя среда:

Host OS: Centos 6.5 64-bit

Cassandra: 2.1.2, raw binary package (not rpm installed)

Java 7 (Oracle)

Firewall closed

two nodes in the same LAN

Я также пробовал много раз, но эта проблема просто не может быть решена. Наконец, я решил удалить как текущие бинарные файлы Cassandra, так и начать с всего нового извлеченного пакета.

Удивительно, но это работает.

Затем я переделаю все свои конфигурации и запустил Cassandra, на этот раз проблем не возникнет. Оба узла запущены и кластер успешно сформирован.

Я знаю, что это вряд ли можно назвать «решением» этой проблемы, но я просто хочу поделиться своим опытом здесь. Мне интересно, может быть, какая-то кешированная информация вызвала эту проблему?

источник

2014-11-27 05:37:56 Flickerlight

См: How do you fix node token collision issues when starting up Cassandra nodes in a cluster on VMWare?

«Убедитесь в том, чтобы удалить каталоги Информация о местоположении, которые содержат данные о кластере»

Я удалил следующие папки, то он работает отлично