Re: increased RF and repair, not working?
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--4f7cf9240aef: [192.168.1.129, 192.168.1.40, 192.168.1.50]/ the loads are as below: /nodetool -h localhost ring/ /Address DC RackStatus State Load OwnsToken / / 113427455640312821154458202477256070484 / /192.168.1.50datacenter1 rack1 Up Normal 28.77 GB 33.33% 0 / /192.168.1.40datacenter1 rack1 Up Normal 26.67 GB 33.33% 56713727820156410577229101238628035242 / /192.168.1.129 datacenter1 rack1 Up Normal 33.25 GB 33.33% 113427455640312821154458202477256070484 /
Re: Schema question : Query to support Find which all of these 500 email ids have been registered
Sorry for the confusion created. I need to store emails registered just for a single application. So although my data model would fit into just a single row. But is storing a hundred million columns(col name size= 8 byte; col value size=4 byte ) in a single row a good idea ? I am very much tempted to store it in single row but I also heard it is recommended to keep a row size within 10s of MBs for optimal performance.
is it possible to disable compaction per CF ?
Hello! if we are dealing with append-only data model, so what if I disable compaction on certain CF ? any side effect ? can I do it with update column family with compaction_strategy = null ? Cheers, Ilya Shipitsin
Re: is it possible to disable compaction per CF ?
setMaxCompactionThreshold(0) setMinCompactionThreshold(0) 2012/7/27 Илья Шипицин chipits...@gmail.com Hello! if we are dealing with append-only data model, so what if I disable compaction on certain CF ? any side effect ? can I do it with update column family with compaction_strategy = null ? Cheers, Ilya Shipitsin
Re: restoring a counter
a) how does that setting affect C* in a non-restoring start? renew_counter_id regenerates a new NodeId for the cassandra VM which is used to keep track of the counter shards the node holds. If you regenerate node ids on each restart, you will most likely corrupt your counter data. The description of NodeId is correct but the part about regenerating it could lead to counter data corruption is not. There is no risk of corrupting counter by regenerating the node id too often (or at least there should not be), but it does have an impact on performance. Basically, if you restart with the -Dcassandra.renew_counter_id=true, the internal representation for your counter will become bigger (the size occupied on disk, not the counter value itself) over time. And by over time I mean, with new counter increment coming in. So if you restart even a few times with the flag on over a short period of time, it's fine, it won't have much negative impact, but in general it is a one shot flag and you should not leave it on. b) if it's bad (for some value of that), should I stop C*+remove the setting+start C* after the value has been repaired? The short answer is no. The renewal of the node id that the flag trigger is done at startup and once it's done, it's done. When you start with the flag on, the only thing you want to make sure is to not have the flag on for the next restart, but there is no reason to force that restart. -- Sylvain
Re: Schema question : Query to support Find which all of these 500 email ids have been registered
What about if I spread these columns across 20 rows ? Then I have to query each of these 20 rows for 500 columns. but still this seems a better solution than one row for all cols or separate row for each email id approaches !? On Fri, Jul 27, 2012 at 11:36 AM, Aklin_81 asdk...@gmail.com wrote: Sorry for the confusion created. I need to store emails registered just for a single application. So although my data model would fit into just a single row. But is storing a hundred million columns(col name size= 8 byte; col value size=4 byte ) in a single row a good idea ? I am very much tempted to store it in single row but I also heard it is recommended to keep a row size within 10s of MBs for optimal performance.
Re: Questions regarding DataStax AMI
HI! I tried starting a cluster with Cluster started with these options: --clustername Name --totalnodes 3 --version community --release 1.0.8 But Cassandra's version is 1.1.2 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 Thu, Jul 26, 2012 at 9:56 PM, Tamar Fraenkel ta...@tok-media.com wrote: What should be the value to create it with Cassandra 1.0.8 Tamar Sent from my iPod On Jul 26, 2012, at 7:06 PM, Joaquin Casares joaq...@datastax.com wrote: Yes, you can easily do this by using the --release version switch as found here: http://www.datastax.com/docs/1.0/install/install_ami Thanks, Joaquin Casares DataStax Software Engineer/Support On Thu, Jul 26, 2012 at 12:44 AM, Tamar Fraenkel ta...@tok-media.comwrote: Hi! Is there a way to launch EC2 cluster from DataStax latest community AMI that will run Cassandra 1.0.8 and not 1.1.2? Thanks *Tamar Fraenkel * Senior Software Engineer, TOK Media tokLogo.png ta...@tok-media.com Tel: +972 2 6409736 Mob: +972 54 8356490 Fax: +972 2 5612956 tokLogo.png
Re: Unreachable node, not in nodetool ring
Hi again, Nobody has a clue about this issue ? I'm still facing this problem. Alain 2012/7/23 Alain RODRIGUEZ arodr...@gmail.com: Does anyone knows how to totally remove a dead node that only appears when doing a describe cluster from the cli ? I still got this issue in my production cluster. Alain 2012/7/20 Alain RODRIGUEZ arodr...@gmail.com: Hi Aaron, I have repaired and cleanup both nodes already and I did it after any change on my ring (It tooks me a while btw :)). The node *.211 is actually out of the ring and out of my control 'cause I don't have the server anymore (EC2 instance terminated a few days ago). Alain 2012/7/20 aaron morton aa...@thelastpickle.com: I would: * run repair on 10.58.83.109 * run cleanup on 10.59.21.241 (I assume this was the first node). It looks like 0.56.62.211 is out of the cluster. Cheers - Aaron Morton Freelance Developer @aaronmorton http://www.thelastpickle.com On 19/07/2012, at 9:37 PM, Alain RODRIGUEZ wrote: Not sure if this may help : nodetool -h localhost gossipinfo /10.58.83.109 RELEASE_VERSION:1.1.2 RACK:1b LOAD:5.9384978406E10 SCHEMA:e7e0ec6c-616e-32e7-ae29-40eae2b82ca8 DC:eu-west STATUS:NORMAL,85070591730234615865843651857942052864 RPC_ADDRESS:0.0.0.0 /10.248.10.94 RELEASE_VERSION:1.1.2 LOAD:3.0128207422E10 SCHEMA:e7e0ec6c-616e-32e7-ae29-40eae2b82ca8 STATUS:LEFT,0,1342866804032 RPC_ADDRESS:0.0.0.0 /10.56.62.211 RELEASE_VERSION:1.1.2 LOAD:11594.0 RACK:1b SCHEMA:59adb24e-f3cd-3e02-97f0-5b395827453f DC:eu-west REMOVAL_COORDINATOR:REMOVER,85070591730234615865843651857942052864 STATUS:removed,170141183460469231731687303715884105727,1342453967415 RPC_ADDRESS:0.0.0.0 /10.59.21.241 RELEASE_VERSION:1.1.2 RACK:1b LOAD:1.08667047094E11 SCHEMA:e7e0ec6c-616e-32e7-ae29-40eae2b82ca8 DC:eu-west STATUS:NORMAL,0 RPC_ADDRESS:0.0.0.0 Story : I had 2 node cluster 10.248.10.94 Token 0 10.59.21.241 Token 85070591730234615865843651857942052864 Had to replace node 10.248.10.94 so I add 10.56.62.211 on token 0 - 1 (170141183460469231731687303715884105727). This failed, I removed token. I repeat the previous operation with the node 10.59.21.241 and it went fine. Next I decommissionned the node 10.248.10.94 and moved 10.59.21.241 to the token 0. Now I am on the situation described before. Alain 2012/7/19 Alain RODRIGUEZ arodr...@gmail.com: Hi, I wasn't able to see the token used currently by the 10.56.62.211 (ghost node). I already removed the token 6 days ago : - Removing token 170141183460469231731687303715884105727 for /10.56.62.211 - check in cassandra log. It is possible you see a log line telling you 10.56.62.211 and 10.59.21.241 o 10.58.83.109 share the same token Nothing like that in the logs I tried the following without success : $ nodetool -h localhost removetoken 170141183460469231731687303715884105727 Exception in thread main java.lang.UnsupportedOperationException: Token not found. ... I really thought this was going to work :-). Any other ideas ? Alain PS : I heard that Octo is a nice company and you use Cassandra so I guess you're fine in there :-). I wish you the best thanks for your help. 2012/7/19 Olivier Mallassi omalla...@octo.com: I got that a couple of time (due to DNS issues in our infra) what you could try - check in cassandra log. It is possible you see a log line telling you 10.56.62.211 and 10.59.21.241 o 10.58.83.109 share the same token - if 10.56.62.211 is up, try decommission (via nodetool) - if not, move 10.59.21.241 or 10.58.83.109 to current token + 1 - use removetoken (via nodetool) to remove the token associated with 10.56.62.211. in case of failure, you can use removetoken -f instead. then, the unreachable IP should have disappeared. HTH On Thu, Jul 19, 2012 at 10:38 AM, Alain RODRIGUEZ arodr...@gmail.com wrote: Hi, I tried to add a node a few days ago and it failed. I finally made it work with an other node but now when I describe cluster on cli I got this : Cluster Information: Snitch: org.apache.cassandra.locator.Ec2Snitch Partitioner: org.apache.cassandra.dht.RandomPartitioner Schema versions: UNREACHABLE: [10.56.62.211] e7e0ec6c-616e-32e7-ae29-40eae2b82ca8: [10.59.21.241, 10.58.83.109] And nodetool ring gives me : Address DC RackStatus State Load OwnsToken 85070591730234615865843651857942052864 10.59.21.241eu-west 1b Up Normal 101.17 GB 50.00% 0 10.58.83.109eu-west 1b Up Normal 55.27 GB 50.00% 85070591730234615865843651857942052864 The point, as you can see, is that one of my node has twice the information of the second one. I have a RF = 2 defined. My guess is that the token 0 node keep data for the unreachable node. The IP of
Re: Unreachable node, not in nodetool ring
nope my last ideas would be (and I am not sure these are the best) - try removetoken with -f option. I do not believe it will change anything but... - try nodeltool ring on ALL nodes and check all nodes see the unreachable node. If not, you could maybe juste decommission the one(s) that see the unreachable node. - If you are in test, you can delete the system folder (subfolder of where all your data are saved (data_directory in cassandra.yaml, by default /var/lib/cassandra/data). *but you will lose everything* - snapshot data and restore them in another cluster. not that simple depending on data volume, traffic etc From my side, I do not have more ideas...and once again, I am not the sure these ones are the best ;) I do not know if cassandra is able to definitively consider a node as dead after a certain amount of time. On Fri, Jul 27, 2012 at 11:04 AM, Alain RODRIGUEZ arodr...@gmail.comwrote: Hi again, Nobody has a clue about this issue ? I'm still facing this problem. Alain 2012/7/23 Alain RODRIGUEZ arodr...@gmail.com: Does anyone knows how to totally remove a dead node that only appears when doing a describe cluster from the cli ? I still got this issue in my production cluster. Alain 2012/7/20 Alain RODRIGUEZ arodr...@gmail.com: Hi Aaron, I have repaired and cleanup both nodes already and I did it after any change on my ring (It tooks me a while btw :)). The node *.211 is actually out of the ring and out of my control 'cause I don't have the server anymore (EC2 instance terminated a few days ago). Alain 2012/7/20 aaron morton aa...@thelastpickle.com: I would: * run repair on 10.58.83.109 * run cleanup on 10.59.21.241 (I assume this was the first node). It looks like 0.56.62.211 is out of the cluster. Cheers - Aaron Morton Freelance Developer @aaronmorton http://www.thelastpickle.com On 19/07/2012, at 9:37 PM, Alain RODRIGUEZ wrote: Not sure if this may help : nodetool -h localhost gossipinfo /10.58.83.109 RELEASE_VERSION:1.1.2 RACK:1b LOAD:5.9384978406E10 SCHEMA:e7e0ec6c-616e-32e7-ae29-40eae2b82ca8 DC:eu-west STATUS:NORMAL,85070591730234615865843651857942052864 RPC_ADDRESS:0.0.0.0 /10.248.10.94 RELEASE_VERSION:1.1.2 LOAD:3.0128207422E10 SCHEMA:e7e0ec6c-616e-32e7-ae29-40eae2b82ca8 STATUS:LEFT,0,1342866804032 RPC_ADDRESS:0.0.0.0 /10.56.62.211 RELEASE_VERSION:1.1.2 LOAD:11594.0 RACK:1b SCHEMA:59adb24e-f3cd-3e02-97f0-5b395827453f DC:eu-west REMOVAL_COORDINATOR:REMOVER,85070591730234615865843651857942052864 STATUS:removed,170141183460469231731687303715884105727,1342453967415 RPC_ADDRESS:0.0.0.0 /10.59.21.241 RELEASE_VERSION:1.1.2 RACK:1b LOAD:1.08667047094E11 SCHEMA:e7e0ec6c-616e-32e7-ae29-40eae2b82ca8 DC:eu-west STATUS:NORMAL,0 RPC_ADDRESS:0.0.0.0 Story : I had 2 node cluster 10.248.10.94 Token 0 10.59.21.241 Token 85070591730234615865843651857942052864 Had to replace node 10.248.10.94 so I add 10.56.62.211 on token 0 - 1 (170141183460469231731687303715884105727). This failed, I removed token. I repeat the previous operation with the node 10.59.21.241 and it went fine. Next I decommissionned the node 10.248.10.94 and moved 10.59.21.241 to the token 0. Now I am on the situation described before. Alain 2012/7/19 Alain RODRIGUEZ arodr...@gmail.com: Hi, I wasn't able to see the token used currently by the 10.56.62.211 (ghost node). I already removed the token 6 days ago : - Removing token 170141183460469231731687303715884105727 for /10.56.62.211 - check in cassandra log. It is possible you see a log line telling you 10.56.62.211 and 10.59.21.241 o 10.58.83.109 share the same token Nothing like that in the logs I tried the following without success : $ nodetool -h localhost removetoken 170141183460469231731687303715884105727 Exception in thread main java.lang.UnsupportedOperationException: Token not found. ... I really thought this was going to work :-). Any other ideas ? Alain PS : I heard that Octo is a nice company and you use Cassandra so I guess you're fine in there :-). I wish you the best thanks for your help. 2012/7/19 Olivier Mallassi omalla...@octo.com: I got that a couple of time (due to DNS issues in our infra) what you could try - check in cassandra log. It is possible you see a log line telling you 10.56.62.211 and 10.59.21.241 o 10.58.83.109 share the same token - if 10.56.62.211 is up, try decommission (via nodetool) - if not, move 10.59.21.241 or 10.58.83.109 to current token + 1 - use removetoken (via nodetool) to remove the token associated with 10.56.62.211. in case of failure, you can use removetoken -f instead. then, the unreachable IP should have disappeared. HTH On Thu, Jul 19,
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.comwrote: 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--4f7cf9240aef: [192.168.1.129, 192.168.1.40, 192.168.1.50]* the loads are as below: *nodetool -h localhost ring* *Address DC RackStatus State Load OwnsToken * * 113427455640312821154458202477256070484 * *192.168.1.50datacenter1 rack1 Up Normal 28.77 GB 33.33% 0 * *192.168.1.40datacenter1 rack1 Up Normal 26.67 GB 33.33% 56713727820156410577229101238628035242 * *192.168.1.129 datacenter1 rack1 Up Normal 33.25 GB 33.33% 113427455640312821154458202477256070484*
Re: increased RF and repair, not working?
I think Dave is right, I have read this article again: http://thelastpickle.com/2011/07/04/Cassandra-Query-Plans/ I have data on two nodes, and QUORUM read means it need read from both two nodes. I guess I need to increase the RF to 3, to make the system can tolerance one node failure. thanks for all of the kind help! On Fri, Jul 27, 2012 at 8:08 PM, Riyad Kalla rka...@gmail.com wrote: 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.comwrote: 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--4f7cf9240aef: [192.168.1.129, 192.168.1.40, 192.168.1.50]* the loads are as below: *nodetool -h localhost ring* *Address DC RackStatus State Load OwnsToken * * 113427455640312821154458202477256070484 * *192.168.1.50datacenter1 rack1 Up Normal 28.77 GB 33.33% 0 * *192.168.1.40datacenter1 rack1 Up Normal 26.67 GB 33.33% 56713727820156410577229101238628035242 * *192.168.1.129 datacenter1 rack1 Up Normal 33.25 GB 33.33% 113427455640312821154458202477256070484*
Re: increased RF and repair, not working?
Ah! Yan I think you want your writes to use QUORUM and your reads to just be a single node right? If you need/want the read-repair, then I suppose you would need more nodes up (or deployed in your cluster) but if you are keeping 3 machines a RF of 2 with a write consistency of 2 and a read of 1 should give you good behavior with what you have now. On Fri, Jul 27, 2012 at 8:56 AM, Yan Chunlu springri...@gmail.com wrote: I think Dave is right, I have read this article again: http://thelastpickle.com/2011/07/04/Cassandra-Query-Plans/ I have data on two nodes, and QUORUM read means it need read from both two nodes. I guess I need to increase the RF to 3, to make the system can tolerance one node failure. thanks for all of the kind help! On Fri, Jul 27, 2012 at 8:08 PM, Riyad Kalla rka...@gmail.com wrote: 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.comwrote: 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--4f7cf9240aef: [192.168.1.129, 192.168.1.40, 192.168.1.50]* the loads are as below: *nodetool -h localhost ring* *Address DC RackStatus State Load OwnsToken * * 113427455640312821154458202477256070484 * *192.168.1.50datacenter1 rack1 Up Normal 28.77 GB 33.33% 0 * *192.168.1.40datacenter1 rack1 Up Normal 26.67 GB 33.33% 56713727820156410577229101238628035242 * *192.168.1.129 datacenter1 rack1 Up Normal 33.25 GB 33.33% 113427455640312821154458202477256070484*
Re: Unsubscribe
http://wiki.apache.org/cassandra/FAQ#unsubscribe On Fri, Jul 27, 2012 at 9:46 AM, Samir Rayani samir.ray...@gmail.comwrote: -- Tyler Hobbs DataStax http://datastax.com/
Re: increased RF and repair, not working?
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: quot;Riyad Kallaquot; ;rka...@gmail.com
Re: Connection issue in Cassandra
On Thu, Jul 26, 2012 at 11:25 PM, Adeel Akbar adeel.ak...@panasiangroup.com wrote: I used Cassandra 0.8.1 and pycasa 0.2. If I upgrade pycasa, then it have compatibility issue. please suggest You can use the latest version of pycassa with Cassandra 0.8. -- Tyler Hobbs DataStax http://datastax.com/
Re: increased RF and repair, not working?
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.comwrote: 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.comwrote: 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--4f7cf9240aef: [192.168.1.129, 192.168.1.40, 192.168.1.50]* the loads are as below: *nodetool -h localhost ring* *Address DC RackStatus State Load nbsp ;OwnsToken * * 113427455640312821154458202477256070484 * *192.168.1.50datacenter1 rack1 Up Normal 28.77 GB 33.33% 0 * *192.168.1.40datacenter1 rac k1 Up Normal 26.67 GB 33.33% 56713727820156410577229101238628035242 * *192.168.1.129 datacenter1 rack1 Up Normal 33.25 GB 33.33% 113427455640312821154458202477256070484*
Re: Questions regarding DataStax AMI
Oh you're right, sorry about that. The concept of keeping older packages was recently implemented and while using --version community, you would need --release 1.0 in order to get 1.0.10. If you are using --version enterprise, you can use --release 2.0 to get DataStax Enterprise 2.0 which comes bundled with 1.0.8. As long as you don't include --analyticsnodes or --searchnodes, you will get vanilla Cassandra. As of now, those are the only options available. Thanks for pointing that out and sorry about the confusion, Joaquin Casares DataStax Software Engineer/Support On Fri, Jul 27, 2012 at 3:50 AM, Tamar Fraenkel ta...@tok-media.com wrote: HI! I tried starting a cluster with Cluster started with these options: --clustername Name --totalnodes 3 --version community --release 1.0.8 But Cassandra's version is 1.1.2 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 Thu, Jul 26, 2012 at 9:56 PM, Tamar Fraenkel ta...@tok-media.comwrote: What should be the value to create it with Cassandra 1.0.8 Tamar Sent from my iPod On Jul 26, 2012, at 7:06 PM, Joaquin Casares joaq...@datastax.com wrote: Yes, you can easily do this by using the --release version switch as found here: http://www.datastax.com/docs/1.0/install/install_ami Thanks, Joaquin Casares DataStax Software Engineer/Support On Thu, Jul 26, 2012 at 12:44 AM, Tamar Fraenkel ta...@tok-media.comwrote: Hi! Is there a way to launch EC2 cluster from DataStax latest community AMI that will run Cassandra 1.0.8 and not 1.1.2? Thanks *Tamar Fraenkel * Senior Software Engineer, TOK Media tokLogo.png ta...@tok-media.com Tel: +972 2 6409736 Mob: +972 54 8356490 Fax: +972 2 5612956 tokLogo.png
