On Mon, Jul 23, 2012 at 10:24 PM, Eran Chinthaka Withana <eran.chinth...@gmail.com> wrote: > Thanks Brandon for the answer (and I didn't know driftx = Brandon Williams. > Thanks for your awesome support in Cassandra IRC)
Thanks :) > Increasing CL is tricky for us for now, as our RF on that datacenter is 2 > and CL is set to ONE. If we make the CL to be LOCAL_QUORUM, then, if a node > goes down we will have trouble. I will try to increase the RF to 3 in that > data center and set the CL to LOCAL_QUORUM if nothing works out. Increasing the RF and and using LOCAL_QUORUM is the right thing in this case. By choosing CL.ONE, you are agreeing that read misses are acceptable. If they are not, then adjusting your RF/CL is the only path. > About decommissioning, if the node goes down. There is no way of knowing > running that command on that node, right? IIUC, decommissioning should be > run on a node that needs to be decommissioned. Well, decom and removetoken are both ways of removing a node. The former is for a live node, and the latter is for a dead node. Since your node was actually alive you could have decommissioned it. > Coming back to the original question, without touching the CL, can we bring > back a dead node (after fixing it) and somehow tell Cassandra that the node > is backup and do not send read requests until it gets all the data? No, as I said, you are accepting this behavior by choosing CL.ONE. -Brandon
