Ошибка при попытке запустить создание и выбор в cqlsh: NoHostAvailable

Я новичок в DSE и Cassandra. У меня кластер состоит из 3 ДЦ: "аналитический", "dc2", "транс".

Все используют один и тот же профиль DSE с DSEAuth. Итак, проблема в том, что команды LIST и CREATE работают только тогда, когда я использую cqlsh для преобразования DC. Другой будет воспроизводить NoHostAvailabe.

[root@bigdata-142-116 ~]# nodetool status
Datacenter: analytic
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address       Load       Tokens       Owns    Host ID                               Rack
UN  10.0.142.120  50.78 MiB  256          ?       78f58a89-30b3-4646-8762-f8ed528301a9  rack1
UN  10.0.142.121  126.94 MiB  256          ?       7229079d-12c9-4ef6-8753-b79edbcec8cf  rack1
UN  10.0.142.122  35.91 MiB  256          ?       e3c1e9c3-4bd1-4cd0-8479-69ba1b28676e  rack1
UN  10.0.142.123  52.7 MiB   256          ?       25c591fe-36cc-4923-82bc-c0944364b486  rack1
Datacenter: dc2
===============
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address       Load       Tokens       Owns    Host ID                               Rack
UN  10.0.142.116  2.33 GiB   256          ?       9aea87a8-be95-45ad-a9c8-91ad7e658dff  rack2
UN  10.0.142.117  2.64 GiB   256          ?       51e078ec-2434-401c-9db8-4adaaf263ed4  rack1
UN  10.0.142.118  2.76 GiB   256          ?       1a0ccb08-c65d-40ce-ae99-acb30f6e9d9a  rack1
UN  10.0.142.119  2.67 GiB   256          ?       d29708ca-729d-4727-a816-129b4fc72e04  rack1
Datacenter: trans
=================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address       Load       Tokens       Owns    Host ID                               Rack
UN  10.0.142.113  164.09 MiB  256          ?       8fd44e60-9b84-44af-aebf-26b3c6a3ab17  rack1
UN  10.0.142.114  130.3 MiB  256          ?       8eb9a807-ff1f-47d7-92f0-e876f0fb56ee  rack2
UN  10.0.142.115  113.3 MiB  256          ?       e5f9a5d7-03b7-406e-ab0e-e429301af543  rack1

# cqlsh -u cassandra -p cassandra 10.0.142.120
Connected to GDT2 Cluster at 10.0.142.120:9042.
cassandra@cqlsh> list ROLES ;
NoHostAvailable:

# cqlsh -u cassandra -p cassandra 10.0.142.115
Connected to GDT2 Cluster at 10.0.142.115:9042.
cassandra@cqlsh> LIST ROLES ;

 role      | super | login | options
-----------+-------+-------+---------
 cassandra |  True |  True |        {}
  sysadmin |  True |  True |        {}
      test | False |  True |        {}

(3 rows)

cassandra cqlsh cql
person Fiery    schedule 22.10.2019    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Опишите ваше пространство ключей system_auth. Это выглядит так?

> desc KEYSPACE system_auth ;

CREATE KEYSPACE system_auth WITH 
    replication = {'class': 'NetworkTopologyStrategy', 'trans': '1'}
    AND durable_writes = true;

Или, что еще хуже, это выглядит так?

CREATE KEYSPACE system_auth WITH 
    replication = {'class': 'SimpleStrategy', 'replication_factor': '1'}
    AND durable_writes = true;

Проблема здесь в том, что кажется, что trans DC является единственным DC, у которого есть реплики для таблицы system_auth.roles. Чтобы исправить это, я рекомендую следующее:

ALTER KEYSPACE system_auth WITH 
    replication = {'class': 'NetworkTopologyStrategy', 'trans': '3',
    'analytic': '3', 'dc2': '3'};

Это даст указание всем будущим операциям записи в таблицы в ключевом пространстве system_auth записывать 3 реплики в каждый логический центр обработки данных. После завершения этой команды выполните следующее, чтобы убедиться, что все текущие реплики перемещены на свои места:

> consistency ALL
> SELECT * FROM resource_role_permissons_index ;
> SELECT * FROM role_permissions ;
> SELECT * FROM role_members ;
> SELECT * FROM roles;

Первая команда увеличивает уровень согласованности вашего запроса до ALL, требуя ответа от всех реплик для успеха. Это похоже на то, что вы не хотели бы делать в Cassandra (и обычно вы этого не делали). Но чтение с консистенцией ALL вызывает восстановление чтения в 100% случаев. Запросы SELECT считывают все реплики и фактически вызывают восстановление. Это, по сути, обманом заставит Кассандру восстановить реплики для вас.

Также:

cqlsh -u cassandra -p cassandra

Не используйте пользователя cassandra/cassandra по умолчанию. Изменение пароля и/или отключение этой учетной записи — одно из первых действий, которые необходимо сделать.

person Aaron    schedule 22.10.2019
comment
Спасибо Аарон! Кажется, это то, чего мне не хватает в документе: docs.datastax.com /en/security/6.0/security/ Проблема решена после того, как я запустил ALTER для пространств ключей system_auth и dse_security. - person Fiery; 23.10.2019