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 down. 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 rack1 Up Normal 26.67 GB
33.33% 56713727820156410577229101238628035242 /
/192.168.1.129 datacenter1 rack1 Up Normal 33.25 GB
33.33% 113427455640312821154458202477256070484 /
