[
https://issues.apache.org/jira/browse/CASSANDRA-5902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15059874#comment-15059874
]
Branimir Lambov commented on CASSANDRA-5902:
--------------------------------------------
I didn't take that route as I believe the idea wasn't liked earlier because of
the extra hint table traffic which shouldn't be that much of a problem now.
It does make things simpler. New version based on transforming to new hints
directly:
|[code|https://github.com/blambov/cassandra/tree/5902-v2]|[utests|http://cassci.datastax.com/view/Dev/view/blambov/job/blambov-5902-v2-testall/]|[dtests|http://cassci.datastax.com/view/Dev/view/blambov/job/blambov-5902-v2-dtest/]|
> Dealing with hints after a topology change
> ------------------------------------------
>
> Key: CASSANDRA-5902
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5902
> Project: Cassandra
> Issue Type: Sub-task
> Components: Coordination
> Reporter: Jonathan Ellis
> Assignee: Branimir Lambov
> Priority: Minor
> Fix For: 3.0.x, 3.x
>
>
> Hints are stored and delivered by destination node id. This allows them to
> survive IP changes in the target, while making "scan all the hints for a
> given destination" an efficient operation. However, we do not detect and
> handle new node assuming responsibility for the hinted row via bootstrap
> before it can be delivered.
> I think we have to take a performance hit in this case -- we need to deliver
> such a hint to *all* replicas, since we don't know which is the "new" one.
> This happens infrequently enough, however -- requiring first the target node
> to be down to create the hint, then the hint owner to be down long enough for
> the target to both recover and stream to a new node -- that this should be
> okay.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
