2016-01-15 11 views
6

tl; dr Ho risolto il problema di aggiornamento a Cassandra 3.2. Sembra che il problema sia stato This bug.Cassandra leggere errore


Sono in esecuzione di un cluster a due nodi di Cassandra con le versioni [cqlsh 5.0.1 | Cassandra 3.0.1 | CQL spec 3.3.1 | Native protocol v4].

C'è una tabella che non riesco a leggere, ho il seguente errore:

cqlsh:kepler> select type from md_data limit 1; 
Traceback (most recent call last): 
    File "/local/chernals/dsc-cassandra-3.0.1/bin/cqlsh.py", line 1258, in perform_simple_statement 
    result = future.result() 
    File "/local/chernals/dsc-cassandra-3.0.1/bin/../lib/cassandra-driver-internal-only-3.0.0-6af642d.zip/cassandra-driver-3.0.0-6af642d/cassandra/cluster.py", line 3122, in result 
    raise self._final_exception 
ReadFailure: code=1300 [Replica(s) failed to execute read] message="Operation failed - received 0 responses and 1 failures" info={'failures': 1, 'received_responses': 0, 'required_responses': 1, 'consistency': 'ONE'} 

posso leggere altri tavoli senza alcun problema.

Lo schema di tale tabella è:

CREATE TABLE kepler.md_data (
    name text, 
    tag text, 
    id timeuuid, 
    parameter frozen<parameter>, 
    blob_value blob, 
    real_value float, 
    telegram map<text, text> static, 
    text_value text, 
    type text, 
    PRIMARY KEY ((name, tag, id), parameter) 
) WITH CLUSTERING ORDER BY (parameter ASC) 
    AND bloom_filter_fp_chance = 0.01 
    AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'} 
    AND comment = '' 
    AND compaction = {'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 'max_threshold': '32', 'min_threshold': '4'} 
    AND compression = {'chunk_length_in_kb': '64', 'class': 'org.apache.cassandra.io.compress.LZ4Compressor'} 
    AND crc_check_chance = 1.0 
    AND dclocal_read_repair_chance = 0.1 
    AND default_time_to_live = 0 
    AND gc_grace_seconds = 864000 
    AND max_index_interval = 2048 
    AND memtable_flush_period_in_ms = 0 
    AND min_index_interval = 128 
    AND read_repair_chance = 0.0 
    AND speculative_retry = '99PERCENTILE'; 
CREATE INDEX parameter_idx ON kepler.md_data (parameter); 

Ci sarebbero alcuni problemi con un tale schema e le varie versioni di Cassandra/cqlsh sto correndo?

Si noti che quando il tavolo è vuoto, posso "leggerlo" (è vuoto ma l'istruzione select ha esito positivo).

Edit:

problema Super strano come sto attraversando un periodo difficile che riproduce tutto il tempo. Sono passato a una configurazione di prova con solo 1 nodo. Sembra essere collegato al numero di righe presenti nella tabella.

cqlsh:kepler> select type from md_data; 
Traceback (most recent call last): 
    File "/local/chernals/dsc-cassandra-3.0.1/bin/cqlsh.py", line 1258, in perform_simple_statement 
    result = future.result() 
    File "/local/chernals/dsc-cassandra-3.0.1/bin/../lib/cassandra-driver-internal-only-3.0.0-6af642d.zip/cassandra-driver-3.0.0-6af642d/cassandra/cluster.py", line 3122, in result 
    raise self._final_exception 
ReadFailure: code=1300 [Replica(s) failed to execute read] message="Operation failed - received 0 responses and 1 failures" info={'failures': 1, 'received_responses': 0, 'required_responses': 1, 'consistency': 'ONE'} 

cqlsh:kepler> TRUNCATE TABLE md_data; 
cqlsh:kepler> select type from md_data; 

name | tag | id | parameter | blob_value | real_value | telegram | text_value | type 
------+-----+----+-----------+------------+------------+----------+------------+------ 

(0 rows) 
cqlsh:kepler> 

Edit: Messaggio di errore da cassandra -f

WARN 11:07:00 Uncaught exception on thread Thread[SharedPool-Worker-3,5,main]: {} 
java.lang.AssertionError: null 
    at org.apache.cassandra.db.columniterator.AbstractSSTableIterator$IndexState.updateBlock(AbstractSSTableIterator.java:463) ~[apache-cassandra-3.0.1.jar:3.0.1] 
    at org.apache.cassandra.db.columniterator.SSTableIterator$ForwardIndexedReader.computeNext(SSTableIterator.java:268) ~[apache-cassandra-3.0.1.jar:3.0.1] 
    at org.apache.cassandra.db.columniterator.SSTableIterator$ForwardReader.hasNextInternal(SSTableIterator.java:158) ~[apache-cassandra-3.0.1.jar:3.0.1] 
    at org.apache.cassandra.db.columniterator.AbstractSSTableIterator$Reader.hasNext(AbstractSSTableIterator.java:352) ~[apache-cassandra-3.0.1.jar:3.0.1] 
    at org.apache.cassandra.db.columniterator.AbstractSSTableIterator.hasNext(AbstractSSTableIterator.java:219) ~[apache-cassandra-3.0.1.jar:3.0.1] 
    at org.apache.cassandra.db.columniterator.SSTableIterator.hasNext(SSTableIterator.java:32) ~[apache-cassandra-3.0.1.jar:3.0.1] 
    at org.apache.cassandra.db.transform.BaseRows.hasNext(BaseRows.java:108) ~[apache-cassandra-3.0.1.jar:3.0.1] 
    at org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:131) ~[apache-cassandra-3.0.1.jar:3.0.1] 
    at org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:87) ~[apache-cassandra-3.0.1.jar:3.0.1] 
    at org.apache.cassandra.db.rows.UnfilteredRowIteratorSerializer.serialize(UnfilteredRowIteratorSerializer.java:77) ~[apache-cassandra-3.0.1.jar:3.0.1] 
    at org.apache.cassandra.db.partitions.UnfilteredPartitionIterators$Serializer.serialize(UnfilteredPartitionIterators.java:298) ~[apache-cassandra-3.0.1.jar:3.0.1] 
    at org.apache.cassandra.db.ReadResponse$LocalDataResponse.build(ReadResponse.java:136) ~[apache-cassandra-3.0.1.jar:3.0.1] 
    at org.apache.cassandra.db.ReadResponse$LocalDataResponse.<init>(ReadResponse.java:128) ~[apache-cassandra-3.0.1.jar:3.0.1] 
    at org.apache.cassandra.db.ReadResponse$LocalDataResponse.<init>(ReadResponse.java:123) ~[apache-cassandra-3.0.1.jar:3.0.1] 
    at org.apache.cassandra.db.ReadResponse.createDataResponse(ReadResponse.java:65) ~[apache-cassandra-3.0.1.jar:3.0.1] 
    at org.apache.cassandra.db.ReadCommand.createResponse(ReadCommand.java:289) ~[apache-cassandra-3.0.1.jar:3.0.1] 
    at org.apache.cassandra.service.StorageProxy$LocalReadRunnable.runMayThrow(StorageProxy.java:1721) ~[apache-cassandra-3.0.1.jar:3.0.1] 
    at org.apache.cassandra.service.StorageProxy$DroppableRunnable.run(StorageProxy.java:2375) ~[apache-cassandra-3.0.1.jar:3.0.1] 
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) ~[na:1.8.0_66] 
    at org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$FutureTask.run(AbstractTracingAwareExecutorService.java:164) ~[apache-cassandra-3.0.1.jar:3.0.1] 
    at org.apache.cassandra.concurrent.AbstractTracingAwareExecutorService$TraceSessionFutureTask.run(AbstractTracingAwareExecutorService.java:136) [apache-cassandra-3.0.1.jar:3.0.1] 
    at org.apache.cassandra.concurrent.SEPWorker.run(SEPWorker.java:105) [apache-cassandra-3.0.1.jar:3.0.1] 
    at java.lang.Thread.run(Thread.java:745) [na:1.8.0_66] 
+0

1. Ha esaminato i file di registro di Cassandra (/var/log/cassandra/system.log) per cercare possibili errori durante l'esecuzione della query SELECT su una tabella non vuota? 2. Si sta utilizzando la versione cqlsh fornita con il server Cassandra o un'altra versione? – doanduyhai

+0

Sì, 'tail -f logs/system.log' non mostra nulla durante l'esecuzione di una query non riuscita. Sto usando la versione di 'cqlsh' fornita con Cassandra 3. Lo stesso problema si presenta anche con l'ultimo driver python. Sembra davvero che ci sia una "soglia" mentre si popolano i miei dati con i dati di test: funziona fino a un certo punto e poi fallisce. Potrebbe essere che alcune chiazze confondano Cassandra? Quando quel tavolo "fallisce" gli altri sono ancora OK. –

+0

Penso che questo sia questo ragazzo: https://issues.apache.org/jira/browse/CASSANDRA-10903 –

risposta

2

ho risolto il problema l'aggiornamento a Cassandra 3.2. Sembra che il problema sia stato This bug.

+1

Hai davvero provato a inserire alcuni dati nella tabella? Ho riscontrato un errore diverso durante il tentativo di riprodurre questo in 3.0 e 3.2, vedere [CASSANDRA-11021] (https://issues.apache.org/jira/browse/CASSANDRA-11021) –

+0

In realtà ho anche il problema. .. :( –

Problemi correlati