cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Jirsa <Jeff.Ji...@crowdstrike.com>
Subject Re: auto_bootstrap=false broken?
Date Thu, 06 Aug 2015 15:49:36 GMT
You’re trying to force your view onto an established ecosystem. It’s not “wrong only
because its currently bootstrapping”, it’s not bootstrapping at all, you told it not to
bootstrap. 

‘auto_bootstrap’ is the knob that tells cassandra whether or not you want to stream data
from other replicas when you join the ring. Period. That’s all it does. If you set it to
false, you’re telling cassandra it already has the data. The switch implies nothing else.
There is no option to “join the ring but don’t serve reads until I tell you it’s ready”,
and changing auto-bootstrap to be that is unlikely to ever happen. 

Don’t want to serve reads? Disable thrift and native proto, start the with auto-bootstrap
set to whatever you want but thrift and native proto disabled, then enable thrift and native
proto again to enable reads from clients when ready. Until then, make sure you’re using
a consistency level appropriate for your requirements. 

You’re mis-using a knob that doesn’t do what you think it does, and is unlikely to ever
be changed to do what you think it should.


From:  horschi
Reply-To:  "user@cassandra.apache.org"
Date:  Thursday, August 6, 2015 at 3:58 AM
To:  "user@cassandra.apache.org"
Subject:  Re: auto_bootstrap=false broken?

Hi Rob,

 
Your asking the wrong nodes for data in the rebuild-a-new-DC case does not indicate a problem
with the auto_bootstrap false + rebuild paradigm.

The node is "wrong" only because its currently bootstrapping. So imho Cassandra should not
serve any reads in such a case.

 

What makes you think you should be using it in any case other than rebuild-new-DC or "I restored
my node's data with tablesnap"?
 
These two cases are my example use-cases. I don't know if there are any other cases, perhaps
there is.

 

As the bug I pasted you indicates, if you want to repair a node before having it join, use
join_ring=false, repair it, and then join.

https://issues.apache.org/jira/browse/CASSANDRA-6961

In what way does this functionality not meet your needs?
 
I see two reasons why join_ring=false does not help with my issue or I misunderstand:

- When I set up a new node and I start it with join_ring=false, then it does not get any tokens,
right? (I tried it, and that was what I got)  How can I run "nodetool repair" when the node
doesn't have any tokens?

- A node that is not joining the ring, will not receive any writes, right? So if I run repair
in a unjoined state for X hours, then I will miss X hours worth of data afterwards.


The only solution I see seems to be write_survey. I will do some tests with it, once 2.0.17
is out. I will post my results :-)

kind regards,
Christian



Mime
View raw message