cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brandon Williams <dri...@gmail.com>
Subject Re: Bringing a dead node back up after fixing hardware issues
Date Tue, 24 Jul 2012 18:06:29 GMT
On Mon, Jul 23, 2012 at 10:24 PM, Eran Chinthaka Withana
<eran.chinthaka@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

Mime
View raw message