You haven’t said what consistency level you are using. CQLSH by default uses consistency level one which may be part of the issue - try using a higher level (eg CONSISTENCY QUOROM).
After results are returned correctly are they then returned correctly for all future runs? When was the data inserted (relative to your attempt to query it)? Cheers Ben --- *Ben Slater**Chief Product Officer* <https://www.instaclustr.com/platform/> <https://www.facebook.com/instaclustr> <https://twitter.com/instaclustr> <https://www.linkedin.com/company/instaclustr> Read our latest technical blog posts here <https://www.instaclustr.com/blog/>. This email has been sent on behalf of Instaclustr Pty. Limited (Australia) and Instaclustr Inc (USA). This email and any attachments may contain confidential and legally privileged information. If you are not the intended recipient, do not copy or disclose its content, but please reply to this email immediately and highlight the error to the sender and then immediately delete the message. On Mon, 29 Apr 2019 at 17:57, Marco Gasparini < marco.gaspar...@competitoor.com> wrote: > Hi all, > > I'm using Cassandra 3.11.3.5. > > I have just noticed that when I perform a query I get 0 result but if I > launch that same query after few seconds I get the right result. > > I have traced the query: > > cqlsh> select event_datetime, id_url, uuid, num_pages from > mkp_history.mkp_lookup where id_url= 1455425 and url_type='mytype' ; > > event_datetime | id_url | uuid | num_pages > ----------------+--------+------+----------- > > (0 rows) > > Tracing session: dda9d1a0-6a51-11e9-9e36-f54fe3235e69 > > activity > > | timestamp | source | source_elapsed | > client > > ----------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------------------------+-----------+----------------+----------- > > > Execute CQL3 query | 2019-04-29 09:39:05.530000 | 10.8.0.10 | > 0 | 10.8.0.10 > Parsing select event_datetime, id_url, uuid, num_pages from > mkp_history.mkp_lookup where id_url= 1455425 and url_type=' mytype'\n; > [Native-Transport-Requests-2] | 2019-04-29 09:39:05.530000 | 10.8.0.10 | > 238 | 10.8.0.10 > > Preparing statement > [Native-Transport-Requests-2] | 2019-04-29 09:39:05.530000 | 10.8.0.10 | > 361 | 10.8.0.10 > > reading data from /10.8.0.38 > [Native-Transport-Requests-2] | 2019-04-29 09:39:05.531000 | 10.8.0.10 | > 527 | 10.8.0.10 > > Sending READ message to /10.8.0.38 > [MessagingService-Outgoing-/10.8.0.38-Small] | 2019-04-29 09:39:05.531000 | > 10.8.0.10 | 620 | 10.8.0.10 > > READ message received from /10.8.0.10 > [MessagingService-Incoming-/10.8.0.10] | 2019-04-29 09:39:05.535000 | > 10.8.0.8 | 44 | 10.8.0.10 > > speculating read retry on /10.8.0.8 > [Native-Transport-Requests-2] | 2019-04-29 09:39:05.535000 | 10.8.0.10 | > 4913 | 10.8.0.10 > > Executing single-partition query on > mkp_lookup [ReadStage-2] | 2019-04-29 09:39:05.535000 | 10.8.0.8 | > 304 | 10.8.0.10 > > Sending READ message to /10.8.0.8 > [MessagingService-Outgoing-/10.8.0.8-Small] | 2019-04-29 09:39:05.535000 | > 10.8.0.10 | 4970 | 10.8.0.10 > > Acquiring sstable > references [ReadStage-2] | 2019-04-29 09:39:05.536000 | 10.8.0.8 | > 391 | 10.8.0.10 > > Bloom filter allows skipping sstable > 1 [ReadStage-2] | 2019-04-29 09:39:05.536000 | 10.8.0.8 | 490 | > 10.8.0.10 > > Skipped 0/1 non-slice-intersecting sstables, included 0 due to > tombstones [ReadStage-2] | 2019-04-29 09:39:05.536000 | 10.8.0.8 | > 549 | 10.8.0.10 > > Merged data from memtables and 0 > sstables [ReadStage-2] | 2019-04-29 09:39:05.536000 | 10.8.0.8 | > 697 | 10.8.0.10 > > Read 0 live rows and 0 tombstone > cells [ReadStage-2] | 2019-04-29 09:39:05.536000 | 10.8.0.8 | > 808 | 10.8.0.10 > > Enqueuing response to / > 10.8.0.10 [ReadStage-2] | 2019-04-29 09:39:05.536000 | 10.8.0.8 | > 896 | 10.8.0.10 > > Sending REQUEST_RESPONSE message to /10.8.0.10 > [MessagingService-Outgoing-/10.8.0.10-Small] | 2019-04-29 09:39:05.536000 > | 10.8.0.8 | 1141 | 10.8.0.10 > > REQUEST_RESPONSE message received from /10.8.0.8 > [MessagingService-Incoming-/10.8.0.8] | 2019-04-29 09:39:05.539000 | > 10.8.0.10 | 8627 | 10.8.0.10 > > Processing response from /10.8.0.8 > [RequestResponseStage-3] | 2019-04-29 09:39:05.539000 | 10.8.0.10 | > 8739 | 10.8.0.10 > > > Request complete | 2019-04-29 09:39:05.538823 | 10.8.0.10 | 8823 > | 10.8.0.10 > > > > And here I rerun the query just after few seconds: > > > cqlsh> select event_datetime, id_url, uuid, num_pages from > mkp_history.mkp_lookup where id_url= 1455425 and url_type='mytype'; > > event_datetime | id_url | uuid > | num_pages > > ---------------------------------+---------+--------------------------------------+----------- > 2019-04-15 21:32:27.031000+0000 | 1455425 | > 91114c7d-3dd3-4913-ac9c-0dfa12b4198b | 1 > 2019-04-14 21:34:23.630000+0000 | 1455425 | > e97b160d-3901-4550-9ce6-36893a6dcd90 | 1 > 2019-04-11 21:57:23.025000+0000 | 1455425 | > 1566cc7c-7893-43f0-bffe-caab47dec851 | 1 > > (3 rows) > > Tracing session: f4b7eb20-6a51-11e9-9e36-f54fe3235e69 > > activity > > | timestamp | source | source_elapsed | > client > > --------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------------------------+-----------+----------------+----------- > > > Execute CQL3 query | 2019-04-29 09:39:44.210000 | 10.8.0.10 | > 0 | 10.8.0.10 > Parsing select event_datetime, id_url, uuid, num_pages from > mkp_history.mkp_lookup where id_url= 1455425 and url_type='mytype'; > [Native-Transport-Requests-2] | 2019-04-29 09:39:44.210000 | 10.8.0.10 | > 125 | 10.8.0.10 > > READ message received from /10.8.0.10 > [MessagingService-Incoming-/10.8.0.10] | 2019-04-29 09:39:44.211000 | > 10.8.0.8 | 27 | 10.8.0.10 > > Preparing statement > [Native-Transport-Requests-2] | 2019-04-29 09:39:44.211000 | 10.8.0.10 | > 261 | 10.8.0.10 > > Executing single-partition query on mkp_lookup > [ReadStage-1] | 2019-04-29 09:39:44.211000 | 10.8.0.8 | 233 | > 10.8.0.10 > > reading data from /10.8.0.8 > [Native-Transport-Requests-2] | 2019-04-29 09:39:44.211000 | 10.8.0.10 | > 422 | 10.8.0.10 > > Sending READ message to /10.8.0.8 > [MessagingService-Outgoing-/10.8.0.8-Small] | 2019-04-29 09:39:44.211000 | > 10.8.0.10 | 522 | 10.8.0.10 > > Acquiring sstable references > [ReadStage-1] | 2019-04-29 09:39:44.212000 | 10.8.0.8 | 312 | > 10.8.0.10 > > Bloom filter allows skipping sstable 1 > [ReadStage-1] | 2019-04-29 09:39:44.212000 | 10.8.0.8 | 413 | > 10.8.0.10 > > Skipped 0/1 non-slice-intersecting sstables, included 0 due to tombstones > [ReadStage-1] | 2019-04-29 09:39:44.212000 | 10.8.0.8 | 473 | > 10.8.0.10 > > Merged data from memtables and 0 sstables > [ReadStage-1] | 2019-04-29 09:39:44.212000 | 10.8.0.8 | 676 | > 10.8.0.10 > > Read 3 live rows and 0 tombstone cells > [ReadStage-1] | 2019-04-29 09:39:44.212000 | 10.8.0.8 | 794 | > 10.8.0.10 > > Enqueuing response to / > 10.8.0.10 [ReadStage-1] | 2019-04-29 09:39:44.212000 | 10.8.0.8 | > 854 | 10.8.0.10 > > Sending REQUEST_RESPONSE message to /10.8.0.10 > [MessagingService-Outgoing-/10.8.0.10-Small] | 2019-04-29 09:39:44.212001 > | 10.8.0.8 | 1017 | 10.8.0.10 > > REQUEST_RESPONSE message received from /10.8.0.8 > [MessagingService-Incoming-/10.8.0.8] | 2019-04-29 09:39:44.214000 | > 10.8.0.10 | 4117 | 10.8.0.10 > > Processing response from /10.8.0.8 > [RequestResponseStage-3] | 2019-04-29 09:39:44.214000 | 10.8.0.10 | > 4191 | 10.8.0.10 > > > Request complete | 2019-04-29 09:39:44.214349 | 10.8.0.10 | 4349 > | 10.8.0.10 > What is the reason of this behaviour? How can I fix this? > > Thanks > Marco >
