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)

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

16 ответов

Решение

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

Проверьте ваш cassandra.yaml и убедитесь, что значения "listen_address" и "seed" совпадают, за исключением того, что значение 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. broadcast_rpc_address а также listen_address должен быть установлен на локальный IP (не localhost или 127.0.0.1)

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

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

У меня была такая же проблема на 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: "<ip1>,<ip2>,<ip3>"
          - 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-адреса. и это работает.

Для быстрой настройки одного узла на 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

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

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

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

В моем случае я просто обновил свое программное обеспечение и перезагрузил компьютер. Так что это явно не было проблемой соединения между компьютерами (у меня есть брандмауэры и 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-seed-nodes

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

Благодаря Элвингу

Его ответ просто напоминает мне, мне нужно убедиться, что все узлы должны иметь возможность общаться друг с другом.
https://support.datastax.com/hc/en-us/articles/209691483-Bootstap-fails-with-Unable-to-gossip-with-any-seeds-yet-new-node-can-connect-to-seed-nodes

Сплетни должны быть двунаправленными.

Для проверки используйте этот комманд, и вам нужно проверить с обеих сторон

nc -vz {your_node_ip} 7000

Потом я вспомнил, что вчера вечером включил свой брандмауэр Ubuntu. Я открываю это

sudo ufw разрешить 7000/tcp

И это работает сейчас

Я получил ту же ошибку. Может быть более одного решения. Надеюсь, моя ошибка в том, что вы сделали.

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

127.0.0.1 www.example.com

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

127.0.0.1  localhost

127.0.0.1  www.example.com

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

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

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

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

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

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

Получение ошибки при запуске/загрузке

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

указывает на наличие проблемы с Broad_address. широковещательный_адрес отвечает за связь с другими узлами, а не с клиентами.

Этот адрес должен быть установлен в начальном узле (обязателен для начального узла). Если вы используете облачные виртуальные машины, у вас могут быть разные IP-адреса (общедоступные и частные), поэтому рекомендуется использовать ваши частные IP-адреса для широковещательного_адреса, это сэкономит ваши n/w затраты, поскольку Что ж.

      # Address to broadcast to other Cassandra nodes
# Leaving this blank will set it to the same value as listen_address
broadcast_address: 10.11.xx.xxx

В моем сценарии я использовал IBM, и как только я установил широковещательный_адрес в начальных узлах, проблема была решена.

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

в cassandra.yamlизменение listen_addressзначение от localhostк domainNameрешил мою проблему

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

Другие вопросы по тегам