[
https://issues.apache.org/jira/browse/CASSANDRA-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12743010#action_12743010
]
Sandeep Tata commented on CASSANDRA-195:
----------------------------------------
Thanks. I fixed the minor stuff.
This leaves 2 things:
1.
>> I'm really -1 on trying to be clever and second-guessing the op. It just
>> leads to confusion, e.g. when we had the CF definitions stored locally as
>> well as in the xml -- it seemed like adding new CFs to the xml should Just
>> Work but it didn't because Cassandra was outsmarting you.
Okay. I'll change this back so it does exactly what the op wants. But I'll
still write a warning to the log if the restart is in normal mode and the node
remembers that it didn't finish bootstrap.
2.
>>I don't think this is quite right. Introducing the new node into the right
>>place on the ring, but then trying to special case it to not get used, seems
>>problematic. (What if you only have a replication factor of one? Then the
>>data will just disappear until boostrap is complete.)
Can we instead not introduce the bootstraping node into the ring until it is
done? And have the nodes providing data to it, echo writes in the bootstrap
range over?
I didn't think about the replication factor=1 case. The fix is a little more
involved than just maintaining tokenmetadata correctly based on whether we see
a "bootstrap" flag in gossip. I'll make these changes for v4.
> Improve bootstrap algorithm
> ---------------------------
>
> Key: CASSANDRA-195
> URL: https://issues.apache.org/jira/browse/CASSANDRA-195
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Environment: all
> Reporter: Sandeep Tata
> Assignee: Sandeep Tata
> Fix For: 0.5
>
> Attachments: 195-v1.patch, 195-v2.patch, 195-v3.patch
>
>
> When you add a node to an existing cluster and the map gets updated, the new
> node may respond to read requests by saying it doesn't have any of the data
> until it gets the data from the node(s) the previously owned this range (the
> load-balancing code, when working properly can take care of this). While this
> behaviour is compatible with eventual consistency, it would be much
> friendlier for the new node not to "surface" in the EndPoint maps for reads
> until it has transferred the data over from the old nodes.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
