cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Jirsa <>
Subject Re: Bootstrapping a new Node with Consistency=ONE
Date Thu, 03 Aug 2017 07:02:01 GMT
"nodetool status" shows node as UN (up normal) instead of UJ (up joining)

What you're describing really sounds odd. Something isn't adding up to me but I'm not sure
why. You shouldn't be able to query it directly until its bootstrapped as far as I know

Are you sure you're not joining as a seed node? Or with auto bootstrap set to false?

Jeff Jirsa

> On Aug 2, 2017, at 11:52 PM, Daniel Hölbling-Inzko <>
> Thanks Jeff. How do I determine that bootstrap is finished? Haven't seen that anywhere
so far. 
> Reads via storage would be ok as every query would be checked by another node too. I
was only seeing inconsistencies since clients went directly to the node with Consistency ONE
> Greetings 
> Jeff Jirsa <> schrieb am Mi. 2. Aug. 2017 um 16:01:
>> By the time bootstrap is complete it should be as consistent as the source node -
you can change start_native_transport to false to avoid serving clients directly (tcp/9042),
but it'll still serve reads via the storage service (tcp/7000), but the guarantee is that
data should be consistent by the time bootstrap finishes
>> --
>> Jeff Jirsa
>> > On Aug 2, 2017, at 1:53 AM, Daniel Hölbling-Inzko <>
>> >
>> > Hi,
>> > It's probably a strange question but I have a heavily read-optimized payload
where data integrity is not a big deal. So to keep latencies low I am reading with Consistency
ONE from my Multi-DC Cluster.
>> >
>> > Now the issue I saw is that I needed to add another Cassandra node (for redundancy
>> > Since I want this for renduncancy I booted the node and then changed the Replication
of my Keyspace to include the new node (all nodes have 100% of the data).
>> >
>> > The issue I was seeing is that clients that connected to the new Node afterwards
were seeing incomplete data - so the Key would already be present, but the columns would all
be null values.
>> > I expect this to die down once the node is fully replicated, but in the meantime
a lot of my connected clients were in trouble. (The application can handle seeing old data
- incomplete is another matter all together)
>> >
>> > The total data in question is a negligible 500kb (so nothing that should really
take any amount of time in my opinion but it took a few minutes for the data to replicate
over and I am still not sure everything is replicated correctly).
>> >
>> > Increasing the RF to something higher won't really help as the setup is dc1:
3; dc2: 2 (I added the second node in dc2). So a LOCAL_QUORUM in dc2 would still be 2 nodes
which means I just can't loose either of them. Adding a third node is not really cost effective
for the current workloads these nodes need to handle.
>> >
>> > Any advice on how to avoid this in the future? Is there a way to start up a
node that does not serve client requests but does replicate data?
>> >
>> > greetings Daniel
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

View raw message