[
https://issues.apache.org/jira/browse/CASSANDRA-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12744680#action_12744680
]
Sandeep Tata commented on CASSANDRA-195:
----------------------------------------
Here's the scenario for why forwarding logic will need to know the set of
bootstrapNodes:
We have node A, B, C and the new node enters between B and C to get: A, B, N, C.
Say we use B (among other nodes) to bootstrap the data on N.
We still want to be able to forward writes that arrive at P, Q, R, etc intended
for A B C or B C D to reach A B N C. Which means every node needs to know the
nodes that are being bootstrapped and their locations on the ring (not just the
nodes that are bootstrapping the new node which know what ranges they are
sending N). That's why we're storing the bootstrapNodes in tokenMetadata.
When insert or insertBlocking ask for R storage endpoints, we want to pick R +
bootstrapping nodes to receive the update.
> 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-delta1.patch,
> 195-v3.patch, 195-v4.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.
