Доступность Кассандры

Я столкнулся с проблемой «me.prettyprint.hector.api.exceptions.HUnavailableException:: может быть недостаточно реплик для обработки уровня согласованности». когда у меня RF=1, Read Consistency Level = 1 и один из узлов в кольце/кластере из 6 узлов не работает. Все мои чтения терпят неудачу с этим исключением. Есть идеи? В идеале только операции чтения, которые ищут данные на узле, который не работает, должны завершаться неудачей, а все остальные операции чтения должны быть успешными?


person Vinay Kumar Chella    schedule 05.09.2012    source источник
comment
Вы видите ту же проблему, используя cqlsh? Гектор, возможно, пытается быть слишком умным и самостоятельно определять доступность.   -  person jbellis    schedule 06.09.2012
comment
да. Я попробовал CQLSH, и это та же проблема.   -  person Vinay Kumar Chella    schedule 06.09.2012


Ответы (2)


Возможностей может быть несколько:

  • Вы выполняете многострочный запрос (get_range, get_indexed_slices, multiget или эквиваленты cql), который требует, чтобы несколько узлов были активны.
  • Ваш кластер несбалансирован, а нижний узел владеет большей частью кольца; плохая конфигурация с несколькими постоянными токами также может привести к чему-то подобному.
  • Ваш кластер с самого начала был не в хорошем состоянии, когда одни узлы не видят другие. Убедитесь, что кольцо nodetool показывает один и тот же результат при запуске на каждом узле в кластере.

Если ни одна из них не является причиной, дважды проверьте, правильно ли вы указываете уровень согласованности с помощью Hector и cqlsh.

person Tyler Hobbs    schedule 06.09.2012

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

Если вы еще не знаете имена своих контроллеров домена, в оболочке на одном из узлов запустите:

$ nodetool -h localhost ring
Address         DC          Rack        Status State   Load            Owns    Token                                       
                                                                               141784319550391000000000000000000000000     
172.26.233.135  Cassandra   rack1       Up     Normal  25.75 MB        16.67%  0                                           
172.26.233.136  Cassandra   rack1       Up     Normal  26.03 MB        16.67%  28356863910078200000000000000000000000      
172.26.233.137  Cassandra   rack1       Up     Normal  27.19 MB        16.67%  56713727820156400000000000000000000000      
172.26.233.138  Cassandra   rack1       Up     Normal  26.78 MB        16.67%  85070591730234600000000000000000000000      
172.26.233.139  Solr        rack1       Up     Normal  24.47 MB        16.67%  113427455640313000000000000000000000000     
172.26.233.140  Solr        rack1       Up     Normal  26.66 MB        16.67%  141784319550391000000000000000000000000 

Вы можете видеть, что у нас есть два контроллера домена, Cassandra и Solr (это кластер DSE).

В кассандре-кли:

use Keyspace1;
describe;

CLI распечатает параметры стратегии:

Keyspace: Catalog:
  Replication Strategy: org.apache.cassandra.locator.NetworkTopologyStrategy
  Durable Writes: true
    Options: [DC1:3]
...

У нас несоответствие. Cassandra ищет центр обработки данных с именем DC1, отсюда и исключение UnavailableException. Нам нужно обновить параметры репликации, чтобы они соответствовали фактическим контроллерам домена в нашем кластере. В CLI обновите параметры стратегии для вашего пространства ключей, используя имена центров обработки данных:

update keyspace Keyspace1 with strategy_options = {Cassandra:3,Solr:2};
person Andrew Weaver    schedule 06.09.2012
comment
В моем случае схема cassandra была скопирована из производственной среды (в которой было два центра обработки данных) в среду QA (в которой был один центр обработки данных). После исправления схемы для указания одного центра обработки данных проблема была решена. - person zafar142003; 23.06.2016