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