Hi! To clarify it a bit more, Let's assume the setup is changed to RF=3 W_CL=QUORUM (or two for that matter) R_CL=ONE
The setup will now work for both read and write in case of one node failure. What are the disadvantages, other than the disk space needed to replicate everything trice instead of twice? Will it affect also performance? Thanks *Tamar Fraenkel * Senior Software Engineer, TOK Media [image: Inline image 1] ta...@tok-media.com Tel: +972 2 6409736 Mob: +972 54 8356490 Fax: +972 2 5612956 On Fri, Jul 27, 2012 at 11:29 PM, Riyad Kalla <rka...@gmail.com> wrote: > Dave, > > What I was suggesting for Yan was to: > > WRITE: RF=2, CL=QUORUM > READ: CL=ONE > > But you have a good pt... if he hits one of the replicas that didn't have > the data, that would be bad. > > Thanks for clearing that up. > > > On Fri, Jul 27, 2012 at 11:43 AM, Dave Brosius > <dbros...@mebigfatguy.com>wrote: > >> You have RF=2, CL= Quorum but 3 nodes. >> >> So each row is represented on 2 of the 3 nodes. >> >> If you take a node down, one of two things can happen when you attempt to >> read a row. >> >> The row lives on the two nodes that are still up. In this case you will >> successfully read the data. >> >> The row lives on one node that is up, and one node that is down. In this >> case the read will fail because you haven't fulfilled the quorum (2 nodes >> in agreement) requirement. >> >> >> *----- Original Message -----* >> *From:* "Riyad Kalla" <rka...@gmail.com> >> *Sent:* Fri, July 27, 2012 8:08 >> *Subject:* Re: increased RF and repair, not working? >> >> Dave, per my understanding of Yan's description he has 3 nodes and took >> one down manually to test; that should have worked, no? >> >> On Thu, Jul 26, 2012 at 11:00 PM, Dave Brosius >> <dbros...@mebigfatguy.com>wrote: >> >>> Quorum is defined as >>> >>> (replication_factor / 2) + 1 >>> therefore quorum when rf = 2 is 2! so in your case, both nodes must be up. >>> Really, using Quorum only starts making sense as a 'quorum' when RF=3 >>> >>> >>> >>> >>> >>> >>> On 07/26/2012 10:38 PM, Yan Chunlu wrote: >>> >>> I am using Cassandra 1.0.2, have a 3 nodes cluster. the consistency >>> level of read & write are both QUORUM. >>> >>> At first the RF=1, and I figured that one node down will cause the >>> cluster unusable. so I changed RF to 2, and run nodetool repair on every >>> node(actually I did it twice). >>> >>> After the operation I think my data should be in at least two nodes, and >>> it would be okay if one of them is down. >>> >>> But when I tried to simulate the failure, by disablegossip of one node, >>> and the cluster knows this node is dow n. then access data from the >>> cluster, it returned "MaximumRetryException"(pycassa). as my experiences >>> this is caused by "UnavailableException", which is means the data it is >>> requesting is on a node which is down. >>> >>> so I wonder my data might not be replicated right, what should I do? >>> thanks for the help! >>> >>> here is the keyspace info: >>> >>> * >>> * >>> *Keyspace: comments:* >>> * Replication Strategy: org.apache.cassandra.locator.SimpleStrategy* >>> * Durable Writes: true* >>> * Options: [replication_factor:2]* >>> >>> >>> >>> the scheme version is okay: >>> >>> *[default@unknown] describe cluster;* >>> *Cluster Information:* >>> * Snitch: org.apache.cassandra.locator.SimpleSnitch* >>> * Partitioner: org.apache.cassandra.dht.RandomPartitioner* >>> * Schema versions: * >>> * f67d0d50-b923-11e1-0000-4f7cf9240aef: [192.168.1.129, 192.168.1.40, >>> 192.168.1.50]* >>> >>> >>> >>> the loads are as below: >>> >>> *nodetool -h localhost ring* >>> *Address DC Rack Status State Load >>>   ;Owns Token * >>> * >>> 113427455640312821154458202477256070484 * >>> *192.168.1.50 datacenter1 rack1 Up Normal 28.77 GB >>> 33.33% 0 * >>> *192.168.1.40 datacenter1 rac k1 Up Normal 26.67 GB >>> 33.33% 56713727820156410577229101238628035242 * >>> *192.168.1.129 datacenter1 rack1 Up Normal 33.25 GB >>> 33.33% 113427455640312821154458202477256070484 * >>> >>> >> >
<<tokLogo.png>>
