Can you run the trace again for the query "select * " without any conditions and see if you are getting results for tnt_id=5?
On Mon, Nov 23, 2015 at 1:23 PM, Ramon Rockx <[email protected]> wrote: > Hello Oded and Carlos, > > Many thanks for your tips. I modified the consistency level in cqlsh, but > with no success: > > cqlsh> consistency ALL > Consistency level set to ALL. > cqlsh> select * from mls.te where period=62013120356 and tnt_id=5; > > Tracing session: ef0e6590-91e3-11e5-8c24-6783eab735d4 > > activity > | timestamp | source | source_elapsed > ------------------------------------------------------------ > ---------------------+--------------+---------------+---------------- > > execute_cql3_query | 14:13:05,898 | 192.168.0.210 | 0 > Parsing select * from mls.te where period=62013120356 and tnt_id=5 LIMIT > 10000; | 14:13:05,898 | 192.168.0.210 | 40 > Message received from / > 192.168.0.210 | 14:13:05,898 | 192.168.0.211 | 13 > Preparing > statement | 14:13:05,898 | 192.168.0.210 | 276 > Executing single-partition > query on te | 14:13:05,898 | 192.168.0.211 | 259 > Enqueuing data request to / > 192.168.0.211 | 14:13:05,898 | 192.168.0.210 | 526 > Acquiring sstable > references | 14:13:05,898 | 192.168.0.211 | 272 > Enqueuing digest request to / > 192.168.0.212 | 14:13:05,898 | 192.168.0.210 | 565 > Merging memtable > tombstones | 14:13:05,898 | 192.168.0.211 | 301 > Sending message to / > 192.168.0.211 | 14:13:05,898 | 192.168.0.210 | 792 > Bloom filter allows skipping > sstable 1638 | 14:13:05,898 | 192.168.0.211 | 322 > Bloom filter allows skipping > sstable 10 | 14:13:05,898 | 192.168.0.211 | 330 > Merging data from memtables and 0 > sstables | 14:13:05,898 | 192.168.0.211 | 336 > Read 0 live and 0 > tombstoned cells | 14:13:05,898 | 192.168.0.211 | 355 > Sending message to / > 192.168.0.212 | 14:13:05,899 | 192.168.0.210 | 1011 > Enqueuing response to / > 192.168.0.210 | 14:13:05,899 | 192.168.0.211 | 417 > Sending message to / > 192.168.0.210 | 14:13:05,899 | 192.168.0.211 | 1314 > Message received from / > 192.168.0.212 | 14:13:05,901 | 192.168.0.210 | 2950 > Processing response from / > 192.168.0.212 | 14:13:05,901 | 192.168.0.210 | 3014 > Message received from / > 192.168.0.211 | 14:13:05,901 | 192.168.0.210 | 3598 > Processing response from / > 192.168.0.211 | 14:13:05,901 | 192.168.0.210 | 3638 > Message received from / > 192.168.0.210 | 14:13:05,909 | 192.168.0.212 | 28 > Executing single-partition > query on te | 14:13:05,909 | 192.168.0.212 | 276 > Acquiring sstable > references | 14:13:05,909 | 192.168.0.212 | 297 > Merging memtable > tombstones | 14:13:05,909 | 192.168.0.212 | 317 > Bloom filter allows skipping > sstable 1648 | 14:13:05,909 | 192.168.0.212 | 335 > Bloom filter allows skipping > sstable 5 | 14:13:05,909 | 192.168.0.212 | 347 > Merging data from memtables and 0 > sstables | 14:13:05,909 | 192.168.0.212 | 352 > Read 0 live and 0 > tombstoned cells | 14:13:05,909 | 192.168.0.212 | 367 > Enqueuing response to / > 192.168.0.210 | 14:13:05,909 | 192.168.0.212 | 413 > Sending message to / > 192.168.0.210 | 14:13:05,909 | 192.168.0.212 | 695 > Request > complete | 14:13:05,901 | 192.168.0.210 | 3785 > > As you can see all the hosts of this cluster are accessed. I also repaired > the *mls* keyspace on all the 3 hosts. > No luck though. > > Maybe some other suggestions? Thanks! > > Regards, > Ramon >
