Кассандра - невозможно подключиться через cqlsh

У меня проблема с подключением к кассандре через clqsh. Я развернул кластер из 3 узлов на CentOS7. Я мог видеть, что узлы соединяются друг с другом. Выходные данные состояния nodetool приведены ниже:

Datacenter: datacenter1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address    Load       Tokens       Owns (effective)        Host ID     Rack
UN  ${SEED2} 226.47 KiB     1            60,3%                 <hash>     rack1
UN  ${SEED}  190.77 KiB     1            50,9%                 <hash>     rack1
UN  ${IP}    157.62 KiB     1            88,7%                 <hash>    rack1

Но подключение через cqlsh не работает. Я пробовал подключиться к localhost и к IP-адресу узла. Вот результат выполнения команды cqlsh:

[root@node02 default.conf]# cqlsh
Connection error: ('Unable to connect to any servers', {'127.0.0.1': 
error(111, "Tried connecting to [('127.0.0.1', 9042)]. Last error: 
Connection refused")})
[root@node02 default.conf]# cqlsh ${IP}
connection error: ('Unable to connect to any servers', {'${IP}': 
ConnectionShutdown('Connection to ${IP} was closed',)})

Для меня не так очевидно, почему при подключении к rpc_address печатается сообщение «Соединение с ... было закрыто», а при подключении к локальному хосту - «Соединение отклонено». Кто-нибудь знает причину такой проблемы? Ниже приведен файл cassandra.yaml:

# Cassandra storage config YAML

cluster_name: '${NAME}'
hinted_handoff_enabled: true
authenticator: org.apache.cassandra.auth.AllowAllAuthenticator
data_file_directories:
    - /var/lib/cassandra/data
commitlog_directory: /var/lib/cassandra/commitlog
hints_directory: /var/lib/cassandra/hints

key_cache_size_in_mb: 2    
key_cache_save_period: 14400    
row_cache_size_in_mb: 0    
row_cache_save_period: 0

saved_caches_directory: /var/lib/cassandra/saved_caches    
commitlog_sync: periodic
commitlog_sync_period_in_ms: 10000

concurrent_reads: 32
concurrent_writes: 32

storage_port: 7000
ssl_storage_port: 7001

rpc_port: 9042
start_rpc: true
rpc_keepalive: true    
rpc_server_type: sync

request_scheduler: org.apache.cassandra.scheduler.NoScheduler
index_interval: 128

listen_address: ${IP}
rpc_address: ${IP}
seed_provider:
    - class_name: org.apache.cassandra.locator.SimpleSeedProvider
      parameters:
          - seeds: ${IP},${SEED}

person Vitalii Honta    schedule 05.03.2018    source источник
comment
Вы проверили настройки брандмауэра? Выполните iptables -L и убедитесь, что порт 9042 не заблокирован.   -  person Simon Fontana Oscarsson    schedule 05.03.2018
comment
Еще одно примечание, не связанное с этим вопросом. В конфигурации семян вы не должны использовать собственный узел в качестве начального числа (вы все равно можете установить этот узел в качестве начального числа для других узлов), если только он не является первым узлом в кластере. Начальные значения не загружаются, что означает, что когда вы добавляете новые узлы в кластер и устанавливаете их как начальные числа, они не будут передавать какие-либо данные с других узлов. Итак, ваш файл cassandra.yaml должен выглядеть так - seed: $ {SEED}   -  person Simon Fontana Oscarsson    schedule 05.03.2018
comment
брандмауэр еще не установлен ни на одном сервере в кольце кассандры. Я проверил, что порт 9042 прослушивается netstat. tcp 0 0 176.241.109.36:9042 0.0.0.0:* СЛУШАТЬ 992 4923646 9208 / java   -  person Vitalii Honta    schedule 05.03.2018
comment
Спасибо, я изменил свой доступный сценарий, так что собственный IP-адрес не находится в конфигурации семян. Но cqlsh все еще не работает   -  person Vitalii Honta    schedule 05.03.2018
comment
Можете ли вы попробовать телнет порт?   -  person Simon Fontana Oscarsson    schedule 05.03.2018


Ответы (1)


Нашел проблему. Вы устанавливаете rpc_port равным 9042. Я думаю, вы путаете rpc с родным (cql). Rpc - это старый интерфейс, который не рекомендуется в более поздних выпусках. Я бы рекомендовал установить для start_rpc значение false и вернуть rpc_port обратно к значению по умолчанию: 9160.

person Simon Fontana Oscarsson    schedule 05.03.2018
comment
Это нормально) Я изменил конфигурацию, но нет процесса, который слушает 9042. Пробовал и telnet, и netstat. nodetool status вывод такой же, как и раньше - person Vitalii Honta; 05.03.2018
comment
Какая у вас конфигурация для native_transport_port? - person Simon Fontana Oscarsson; 05.03.2018
comment
@ ВіталійГонта Забыл отметить тебя - person Simon Fontana Oscarsson; 05.03.2018
comment
native_transport_port: 9042 - person Vitalii Honta; 05.03.2018
comment
Странный. Возможно, вы сможете провести сравнение с исходной конфигурацией и загрузить результат на сайт, например pastebin. Должна быть какая-то другая конфигурация, которая неверна. - person Simon Fontana Oscarsson; 05.03.2018
comment
Спасибо за помощь! Произошла ошибка в конфигурационном файле, уже исправлена - person Vitalii Honta; 05.03.2018