2012-09-05 25 views
7

Me encuentro con un problema "me.prettyprint.hector.api.exceptions.HUna excepción disponible: puede que no haya suficientes réplicas presentes para manejar el nivel de coherencia". cuando tengo RF = 1, nivel de coherencia de lectura = 1 y uno de los nodos en el anillo/clúster de 6 nodos está inactivo. Todas mis lecturas están fallando con esta excepción. ¿Alguna idea? Idealmente, solo las lecturas que buscan datos en el nodo que está inactivo deberían fallar y todas las demás lecturas deberían ser exitosas.Disponibilidad de Cassandra

+0

¿Ve el mismo problema al usar cqlsh? Hector puede estar tratando de ser demasiado inteligente y hacer su propia detección de disponibilidad. – jbellis

+0

Sí. Intenté CQLSH también es el mismo problema –

Respuesta

4

Podría haber algunas posibilidades:

  • Usted está ejecutando una consulta de varias filas (get_range, get_indexed_slices, Multiget, o los equivalentes CQL) que requiere múltiples nodos a ser hasta
  • El clúster está desequilibrado, y el nodo de abajo posee la mayor parte del anillo; una mala configuración multi-dc también podría producir algo similar
  • Para empezar, su clúster no estaba en buen estado, donde algunos nodos no ven otros. Haga anillo nodetool seguro muestra la misma salida cuando se ejecuta contra cada nodo en el cluster

Si ninguno de los que son la causa, vuelve a comprobar que usted está especificando el nivel de consistencia correctamente con Héctor y cqlsh.

3

He visto algo similar cuando configuré incorrectamente mi configuración de replicación, específicamente tuve los centros de datos incorrectos llamados om la estrategia de replicación. Verifique dos veces cuáles son sus DC (suponiendo que esté utilizando NetworkTopologyStrategy).

Si todavía no conoce sus nombres DC, en una concha en uno de los nodos ejecutan:

$ 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 

Se puede ver que tenemos dos controladores de dominio, Cassandra y Solr (este es un grupo DSE) .

En cassandra-cli:

use Keyspace1; 
describe; 

CLI imprimir las opciones de estrategia:

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

Tenemos un mal partido. Cassandra está buscando un centro de datos llamado DC1, por lo tanto, la excepción no disponible. Necesitamos actualizar las opciones de replicación para que coincidan con los DC reales en nuestro clúster. En CLI, actualice las opciones de estrategia para su espacio de claves usando los nombres del centro de datos:

update keyspace Keyspace1 with strategy_options = {Cassandra:3,Solr:2}; 
+0

En mi caso, tuve el esquema de cassandra copiado del entorno de producción (que tenía dos centros de datos) para el entorno de control de calidad (que tenía un centro de datos). Después de corregir el esquema para indicar un centro de datos, se resolvió el problema. – zafar142003