Apache Cassandra: невозможно сплетничать с любыми семенами

Я построил сервер Cassandra 2.0.3, а затем запустил его. Он запускается, а затем останавливается сообщениями:

X:\MyProjects\cassandra\apache-cassandra-2.0.3-src\bin>cassandra.bat >log.txt java.lang.RuntimeException: Unable to gossip with any seeds at org.apache.cassandra.gms.Gossiper.doShadowRound(Gossiper.java:1160) at org.apache.cassandra.service.StorageService.checkForEndpointCollision (StorageService.java:416) at org.apache.cassandra.service.StorageService.joinTokenRing(StorageServ ice.java:608) at org.apache.cassandra.service.StorageService.initServer(StorageService .java:576) at org.apache.cassandra.service.StorageService.initServer(StorageService .java:475) at org.apache.cassandra.service.CassandraDaemon.setup(CassandraDaemon.ja va:346) at org.apache.cassandra.service.CassandraDaemon.activate(CassandraDaemon .java:461) at org.apache.cassandra.service.CassandraDaemon.main(CassandraDaemon.jav a:504) 

Что я могу изменить, чтобы запустить его?

У меня была аналогичная проблема с моим кластером cassandra v2.0.4, работающим на одном узле.

Проверьте свой cassandra.yaml и убедитесь, что ваши значения «listen_address» и «seed» совпадают, за исключением того, что значение семян требует котировок вокруг него.

Вы можете получить эту проблему, если ваш частный IP-адрес отличается от общедоступного (например, AWS). Например, хозяин считает, что это «172.31.0.2», когда он отображается как «55.70.33.10».

Решение этой проблемы:

 listen_address: 172.31.0.2 broadcast_address: 55.70.33.10 

в cassandra.yaml

  1. Убедитесь, что запись в cluster_name совпадает со всеми узлами в кластере (возможно, вам потребуется удалить хранилище, если вы изменили имя кластера)

  2. Убедитесь, что все узлы могут пинговать друг другу

  3. rpc_broadcast_address и listen_address должны быть установлены на локальный IP (не localhost или 127.0.0.1 )

  4. семена должны указывать на IP-адрес семян (ов)

Если вы находитесь на AWS и используете Ec2MultiRegionSnitch вам нужно будет установить семена на общедоступные IP-адреса, а не на частные IP-адреса.

Для быстрой установки одного узла на RHEL я сделал следующее: Получите информацию о настройке сетевого интерфейса:

 # /sbin/ifconfig -a 

Он перечислит интерфейсы и ip-адреса, к которым они привязаны. Обычно он отображает интерфейс «Ethernet» и «Local Loopback». Получите связанные ip-адреса.

Затем отредактируйте conf / cassandra.yaml:

 rpc_address: [Local Loopback address] broadcast_rpc_address: [Ethernet address] listen_address: [Local Loopback address] broadcast_address: [Ethernet address] listen_on_broadcast_address: true seed_provider: - class_name: org.apache.cassandra.locator.SimpleSeedProvider parameters: - seeds: "[Ethernet address]" 

Затем также откройте правильные порты на брандмауэре Linux, являющиеся 9042, 7000 и 7001. Подробнее об открытии портов в Linux здесь: http://ask.xmodulo.com/open-port-firewall-centos-rhel.html

У меня была та же проблема на Ubuntu 16.04. Я не уверен, какие из этих изменений заставили его работать, где XXX.XXX.XXX.XXX является вашим публичным IP-адресом, ниже приведены выборы cassandra.yaml

 seed_provider: # Addresses of hosts that are deemed contact points. # Cassandra nodes use this list of hosts to find each other and learn # the topology of the ring. You must change this if you are running # multiple nodes! - class_name: org.apache.cassandra.locator.SimpleSeedProvider parameters: # seeds is actually a comma-delimited list of addresses. # Ex: ",," - seeds: "XXX.XXX.XXX.XXX" listen_address: XXX.XXX.XXX.XXX broadcast_address: XXX.XXX.XXX.XXX broadcast_rpc_address: XXX.XXX.XXX.XXX listen_on_broadcast_address: true start_rpc: true rpc_address: XXX.XXX.XXX.XXX 

По какой-то причине мне также пришлось перезапустить мою виртуальную машину. _ (ツ) _ / ¯

в cassandra.yaml, я обновляю семя от имени домена до IP-адреса. и это работает.

Случилось так, что в моей конфигурации были заданы настройки «intial_token» (я думаю, потому что я просто скопировал файл конфигурации из другого члена кластера). После очистки каталога данных, комментирования настроек и перезапуска узла, он отлично работал для меня.

Сегодня я испытал эту ошибку …

Я не мог найти причину ошибки, кроме проблем с синхронизацией.

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

В моем случае я только что обновил свое программное обеспечение и перезапустил компьютер. Таким образом, это явно не проблема связи между компьютером (у меня есть брандмауэры и SSL, чтобы усложнить ситуацию), и узел был подключен до … Таким образом, одна запись, которую я нашел в этом отношении из datastax, не применялась …

https://support.datastax.com/hc/en-us/articles/209691483-Bootstap-fails-with-Unable-to-gossip-with-any-seeds-yet-new-node-can-connect-to- семенные узлы

У меня такая же ошибка. Может быть несколько решений. Надеюсь, моя ошибка – это то, что вы сделали.

У меня был IP-адрес localhost, указывающий на какое-то доменное имя (и я сделал это для того, чтобы серверный контекст моего загрузочного приложения Spring был некоторым доменным именем, например www.example.com:8080 вместо localhost:8080 , и у меня была следующая запись в моем файл hosts в системе Windows).

 127.0.0.1 www.example.com 

Хотя мой пакетный файл cassandra искал localhost которого он не нашел. Итак, я сделал еще одну запись для localhost в файле hosts:

 127.0.0.1 localhost 127.0.0.1 www.example.com 

Добавив его, я открыл новую командную строку, запустил cassandra batch из каталога cassandra bin и затем работал.

Отключите брандмауэр и SELINUX и повторите попытку.

В нашем случае ssl был включен, а конфигурация cassandra.yaml выглядит нормально в соответствии с вышеприведенными комментариями. Затем мы включили отладку ssl путем добавления ниже jvm paramter в cassandra-env.sh -Djavax.net.debug = ssl: рукопожатие

После запуска узла снова мы заметили ниже в файле журнала cassandra

MessagingService-Outgoing-geo2_host / xx.xx.xx.xx, Исключение при ожидании закрытия javax.net.ssl.SSLHandshakeException: Получено фатальное предупреждение: certificate_unknown

После дальнейшего изучения журналов отладки ssl мы узнали, что сертификат недействителен. После исправления этого узла ssl-проблемы удалось присоединиться к кластеру.

У меня была такая же проблема, я проверил порт, использовал tcpdump, netcat для тестирования соединений и, наконец, пришел к истекшим SSL-сертификатам на межсетевом шифровании. Я изменил internode_encryption, чтобы сделать его «none», перезапустил все узлы, и он сработал. До того, как все соседние узлы были опущены. И команда восстановления узла терпела неудачу: «Не получал положительных ответов от всех конечных точек». PS Не оставляйте internode_encryption как ни один в течение длительного времени, просто восстанавливайте сертификаты и включайте их обратно.

Давайте будем гением компьютера.