Re: Inconsistent behavior during read

2015-06-25 Thread Aditya Shetty
Hi If this problem was because of data inconsistencies, it should have been very rare. However, I am seeing this happen very often (almost 50 % of the times). Statistically, this should be very unlikely if the number of replication failures are small. On Thu, Jun 25, 2015 at 11:55 PM, Tyler Hobbs

Re: Inconsistent behavior during read

2015-06-25 Thread Tyler Hobbs
On Thu, Jun 25, 2015 at 1:00 PM, Robert Coli wrote: > [1] or read repair set to 100% combined with a full scan of all data... > which no one does... And this is only true if "full scan" means reading every partition individually. Reads of partition ranges (or a range slice, in old Thrift terms

Re: Inconsistent behavior during read

2015-06-25 Thread Robert Coli
On Thu, Jun 25, 2015 at 5:14 AM, Jack Krupansky wrote: > Hinted handoff - which is what provides eventual consistency - can time > out and be discarded/lost if the cluster is under heavy load or encounters > poor network connectivity or nodes are down for too long, which is what > requires runnin

Re: [MASSMAIL]Re: Inconsistent behavior during read

2015-06-25 Thread Jonathan Haddad
Quorum will give you strong consistency, but if you're using RF=2 you're going to have issues, as Quorum on RF=2 = CL=ALL. You'll want to use RF=3 to make sure you can tolerate failure of a node, otherwise a single node going down will result in unanswerable queries. On Thu, Jun 25, 2015 at 6:37

Re: [MASSMAIL]Re: Inconsistent behavior during read

2015-06-25 Thread Marcos Ortiz
Regards, Aditya. I´m agree with Jack here. In our tests here with read and writes in Cassandra (version 2.1.5), we played with several CL, and QUORUM is the best for us. On 25/06/15 08:14, Jack Krupansky wrote: Hinted handoff - which is what provides eventual consistency - can time out and be

Re: Inconsistent behavior during read

2015-06-25 Thread Jack Krupansky
Hinted handoff - which is what provides eventual consistency - can time out and be discarded/lost if the cluster is under heavy load or encounters poor network connectivity or nodes are down for too long, which is what requires running repair. That's why quorum is the recommended cl for both write

Re: Inconsistent behavior during read

2015-06-25 Thread Alain RODRIGUEZ
Excepted if the node failed to take the write and you have no Hinted Handoff (or for some reason they also failed). Have you tried at QUORUM or even ALL, this would force a synchronous read repair. You can also try to repair directly. Hope this will help, C*heers, Alain 2015-06-25 13:34 GMT+02

Re: Inconsistent behavior during read

2015-06-25 Thread Aditya Shetty
I am using consistency one for both. However, the writes had happened a few days before, so it does not look like an issue of eventual consistency. On Thu, Jun 25, 2015 at 3:59 PM, Perica Milošević < perica.milose...@gmail.com> wrote: > Which ConsistencyLevel do you use for writing and reading of

Re: Inconsistent behavior during read

2015-06-25 Thread Perica Milošević
Which ConsistencyLevel do you use for writing and reading of the data? Cheers, Perica On Thu, Jun 25, 2015 at 12:12 PM, Aditya Shetty wrote: > Hi > > I have a 3 node cassandra cluster with a replication factor of 2. I have a > basic column family which I am reading by primary key. Here is the C

Inconsistent behavior during read

2015-06-25 Thread Aditya Shetty
Hi I have a 3 node cassandra cluster with a replication factor of 2. I have a basic column family which I am reading by primary key. Here is the CF structure: CREATE TABLE reviews_platform.object_stats ( object_owner_id int, object_type int, object_id text, num_of_reviews int,