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

Ответ 1

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

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

Ответ 2

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

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

listen_address: 172.31.0.2
broadcast_address: 55.70.33.10

Ответ 3

в cassandra.yaml

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

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

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

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

Ответ 4

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

Ответ 5

У меня была такая же проблема на Ubuntu 16.04. Я не уверен, какие из этих изменений сделали его XXX.XXX.XXX.XXX, где 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

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

Ответ 6

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

Ответ 7

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

Ответ 8

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

Ответ 9

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

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

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

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

Ответ 10

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

У меня был IP-адрес localhost, указывающий на какое-то имя домена (и я сделал это, чтобы мой серверный серверный сервер Spring - это какое-то доменное имя, например www.example.com:8080, а не localhost:8080, и у меня была следующая запись в файл моих хостов в системе 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 из каталога bin cassandra и затем работал.

Ответ 11

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

Ответ 12

В нашем случае 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 узел смог присоединиться к кластеру.

Ответ 13

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

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

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

Для того, чтобы проверить использование этой commnd, и вам нужен тест с РАСПОЛОЖЕННЫМ

nc -vz {your_node_ip} 7000

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

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

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

Ответ 14

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