: user@cassandra.apache.org
Subject: Re: Issue with Cassandra consistency in results
Hi
This issue used to appear with me . What I figured in my case was
1. I had 3 machines
2. Inserted the data with ONE consistency (i.e there is no guarantee that
data was propagated to remaining nodes
Hi
This issue used to appear with me . What I figured in my case was
1. I had 3 machines
2. Inserted the data with ONE consistency (i.e there is no guarantee that
data was propagated to remaining nodes , cassandra is supposed to take care
of that).
3. Later I figured also that one of machine
The same issue is appearing in CQL Shell as well.
1) Entered into cqlsh
2) SET CONSISTENCY QUORUM;
3) Ran a select * with partition key in where cluase.
First result gave 0 records,
and Next records gave results.
Its really freaking out us at the moment. And nothing in debug.log or
system.log.
The prep is needed. If I recall correctly it must remain in cache for the
query to complete. I don't have the docs to dig out the yaml parm to adjust
query cache. I had run into the problem stress testing a smallish cluster
with many queries at once.
Do you have a sense of how many distinct querie
into debug.log is an option.
If all done already, nevermind.
Gesendet von meinem Windows 10 Phone
Von: Ryan Svihla
Gesendet: Donnerstag, 16. März 2017 18:57
An: user
Betreff: Re: Issue with Cassandra consistency in results
Depends actually, restore just restores what's there, so if only one
Hi reiydelle,
I cannot confirm the range as the volume of data is huge and the query
frequency is also high.
If the cache is the cause of issue, can we increase cache size or is there
solution to avoid dropped prep statements.?
Thank You,
Regards,
Srini
On Thu, Mar 16, 2017 at 2:13 PM, daem
The discard due to oom is causing the zero returned. I would guess a cache
miss problem of some sort, but not sure. Are you using row, index, etc.
caches? Are you seeing the failed prep statement on random nodes (duh,
nodes that have the relevant data ranges)?
*...*
*Daemeon C.M. Reiydelle
Depends actually, restore just restores what's there, so if only one node
had a copy of the data then only one node had a copy of the data meaning
quorum will still be wrong sometimes.
On Thu, Mar 16, 2017 at 1:53 PM, Arvydas Jonusonis <
arvydas.jonuso...@gmail.com> wrote:
> If the data was writt
If the data was written at ONE, consistency is not guaranteed. ..but
considering you just restored the cluster, there's a good chance something
else is off.
On Thu, Mar 16, 2017 at 18:19 srinivasarao daruna
wrote:
> Want to make read and write QUORUM as well.
>
>
> On Mar 16, 2017 1:09 PM, "Ryan
Want to make read and write QUORUM as well.
On Mar 16, 2017 1:09 PM, "Ryan Svihla" wrote:
Replication factor is 3, and write consistency is ONE and read
consistency is QUORUM.
That combination is not gonna work well:
*Write succeeds to NODE A but fails on node B,C*
*Read goes to NODE
Would switching to select partition_key instead of select count(*) help me
any way ?
I know that, Logically they both are same.. but just asking out of
desperation. Is it worth a shot?
On Mar 16, 2017 1:09 PM, "Ryan Svihla" wrote:
Replication factor is 3, and write consistency is ONE
Replication factor is 3, and write consistency is ONE and read
consistency is QUORUM.
That combination is not gonna work well:
*Write succeeds to NODE A but fails on node B,C*
*Read goes to NODE B, C*
If you can tolerate some temporary inaccuracy you can use QUORUM but may
still have th
Replication strategy is SimpleReplicationStrategy.
Smith is : EC2 snitch. As we deployed cluster on EC2 instances.
I was worried that CL=ALL have more read latency and read failures. But
won't rule out trying it.
Should I switch select count (*) to select partition_key column? Would that
be of a
What are your replication strategy and snitch settings?
Have you tried doing a read at CL=ALL? If it's an actual inconsistency
issue (missing data), this should cause the correct results to be returned.
You'll need to run a repair to fix the inconsistencies.
If all the data is actually there, you
Hi Team,
We are struggling with a problem related to cassandra counts, after backup
and restore of the cluster. Aaron Morton has suggested to send this to user
list, so some one of the list will be able to help me.
We are have a rest api to talk to cassandra and one of our query which
fetches cou
15 matches
Mail list logo
