исключение cassandra replica HUnavailableException

Question

У меня есть пара центров обработки данных cassandra 2 с единственной репликацией с каждым центром данных, содержащим единственный узел и каждый центр данных, расположенный на отдельных физических серверах в сети. Если один центр обработки данных сбой, другой будет доступен для чтения и записи, я запустил приложение java на третьем сервере и все, что он работает нормально. Это чтение и письмо кассандре.

Далее я отсоединил, потянул сетевой кабель, 2-й сервер центра обработки данных из сети. Я ожидал, что приложение продолжит работу без каких-либо исключений против 1-го центра обработки данных, но это было не так.

следующее исключение начал происходить в применении:

me.prettyprint.hector.api.exceptions.HUnavailableException: : May not be enough replicas present to handle consistency level. 
     at me.prettyprint.cassandra.service.ExceptionsTranslatorImpl.translate(ExceptionsTranslatorImpl.java:60) 
     at me.prettyprint.cassandra.service.KeyspaceServiceImpl$9.execute(KeyspaceServiceImpl.java:354) 
     at me.prettyprint.cassandra.service.KeyspaceServiceImpl$9.execute(KeyspaceServiceImpl.java:343) 
     at me.prettyprint.cassandra.service.Operation.executeAndSetResult(Operation.java:101) 
     at me.prettyprint.cassandra.connection.HConnectionManager.operateWithFailover(HConnectionManager.java:232) 
     at me.prettyprint.cassandra.service.KeyspaceServiceImpl.operateWithFailover(KeyspaceServiceImpl.java:131) 
     at me.prettyprint.cassandra.service.KeyspaceServiceImpl.getSuperColumn(KeyspaceServiceImpl.java:360) 
     at me.prettyprint.cassandra.model.thrift.ThriftSuperColumnQuery$1.doInKeyspace(ThriftSuperColumnQuery.java:51) 
     at me.prettyprint.cassandra.model.thrift.ThriftSuperColumnQuery$1.doInKeyspace(ThriftSuperColumnQuery.java:45) 
     at me.prettyprint.cassandra.model.KeyspaceOperationCallback.doInKeyspaceAndMeasure(KeyspaceOperationCallback.java:20) 
     at me.prettyprint.cassandra.model.ExecutingKeyspace.doExecute(ExecutingKeyspace.java:85) 
     at me.prettyprint.cassandra.model.thrift.ThriftSuperColumnQuery.execute(ThriftSuperColumnQuery.java:44) 

После того, как я Reconnected сетевого кабеля на 2-й сервер, ошибка остановилась.

Вот более подробную информацию о Кассандре 1.0.10

1) Вот Ниже описывается с Кассандрой на обоих датацентрах

Keyspace: AdvancedAds: 
Replication Strategy: org.apache.cassandra.locator.NetworkTopologyStrategy 
Durable Writes: true 
Options: [DC2:1, DC1:1] 

2) Я побежал инструмент узел кольца против каждого экземпляра

./nodetool -h 111.111.111.111 -p 11000 ring 
Address DC Rack Status State Load Owns Token 
1 
111.111.111.111 DC1 RAC1 # <-- usUp Normal 1.07 GB 100.00% 0 
111.111.111.222 DC2 RAC1 Up Normal 1.1 GB 0.00% 1 

./nodetool -h 111.111.111.222 ring -port 11000 
Address DC Rack Status State Load Owns Token 
1 
111.111.111.111 DC1 RAC1 Up Normal 1.07 GB 100.00% 0 
111.111.111.222 DC2 RAC1 # <-- usUp Normal 1.1 GB 0.00% 1 

3) Я проверил cassandra.yaml

the seeds are 111.111.111.111, 111.111.111.222 

4) Я проверил cassandra-topology.properties

111.111.111.111 

    # Cassandra Node IP=Data Center:Rack 

    # datacenter 1 
    111.111.111.111=DC1:RAC1 # <-- us 

    # datacenter 2 
    111.111.111.222=DC2:RAC1 

    default=DC1:r1 

111.111.111.222 

    # Cassandra Node IP=Data Center:Rack 

    # datacenter 1 
    111.111.111.111=DC1:RAC1 

    # datacenter 2 
    111.111.111.222=DC2:RAC1 # <-- us 

    default=DC1:r1 

5) мы устанавливаем consistencyLevel в LOCAL_QUORUM в нашей Java-приложение следующим образом:

public Keyspace getKeyspace(final String keyspaceName, final String serverAddresses) 
{   
    Keyspace ks = null; 
    Cluster c = clusterMap.get(serverAddresses); 
    if (c != null) 
    {    
     ConfigurableConsistencyLevel policy = new ConfigurableConsistencyLevel(); 
     policy.setDefaultReadConsistencyLevel(consistencyLevel); 
     policy.setDefaultWriteConsistencyLevel(consistencyLevel); 

     // Create Keyspace 
     ks = HFactory.createKeyspace(keyspaceName, c, policy); 
    }   
    return ks; 
} 

Мне сказали, что эта конфигурация будет работать, но, может быть, я что-то упустил.

Спасибо за любую проницательность

Answer 1

Если у вас есть только два узла, и ваши данные будут размещены на узле, который на самом деле вниз, когда требуется последовательность, вы не можете быть в состоянии достичь полной готовности записи. Кассандра будет добиваться того, что с Hinted Handoff, но для уровня согласованности QUORUM UnavailableException будет брошен в любом случае.

То же самое верно при запросе данных, принадлежащих нисходящему узлу.

Однако, похоже, что ваш кластер плохо сбалансирован. Ваш узел 111.111.111.111 владеет 100%, а затем 111.111.111.222, кажется, владеет 0%, глядя на ваши жетоны, они, по-видимому, являются причиной этого.

заказ, как установить начальный маркер здесь: http://www.datastax.com/docs/0.8/install/cluster_init#token-gen-cassandra

Кроме того, вы можете проверить Another Question, который содержит ответ с более причинами, когда ситуация, как это может произойти.

Answer 2

Гектор, как известно, возвращает ложные недопустимые ошибки.Драйвер родной протокол Java не имеет этой проблемы: https://github.com/datastax/java-driver

Answer 3

LOCAL_QUORUM не будет работать, если настроить NetworkTopologyStrategy так:

Options: [DC2:1, DC1:1] # this will make LOCAL_QUORUM and QUORUM fail always 

LOCAL_QUORUM и (по моему опыту) QUORUM требуют центров обработки данных, чтобы иметь по крайней мере, 2 реплики вверх. Если вы хотите, чтобы кворум охватывал ваши центры обработки данных, вам необходимо установить уровень согласованности в агрегированный центр обработки данных TWO.

Другие примеры:

Options: [DC2:3, DC1:1] # LOCAL_QUORUM for clients in DC2 works, QUORUM fails 

Options: [DC2:2, DC1:1] # LOCAL_QUORUM in DC2 works, but down after 1 node failure 
         # QUORUM fails, TWO works.