[
https://issues.apache.org/jira/browse/CASSANDRA-4047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13398214#comment-13398214
]
Jonathan Ellis commented on CASSANDRA-4047:
-------------------------------------------
Ugh, that is pretty messy.
One complication is that the outputformat node can't assume that it will know
ahead of time which replicas it will need to generate hints for (since nodes
can go down after it's started streaming everywhere).
I think that means we'd need to stream a *second* copy (since the first may
have been compacted already) to one of the nodes, after we learn that hints are
needed.
Alternatively... we can do repairs of specific ranges now. What if we stored
as our "hint" the range we streamed, and the node that went down, and then the
live node will run a partial repair with that replica when it comes back up?
> Bulk hinting
> ------------
>
> Key: CASSANDRA-4047
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4047
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Brandon Williams
> Assignee: Brandon Williams
> Fix For: 1.2
>
>
> With the introduction of the BulkOutputFormat, there may be cases where
> someone would like to tolerate node failures and have the job complete, but
> afterwards since we streamed they have to repair or rely on read repair. We
> don't currently have any way of hinting streams, but a node could take a
> snapshot before acknowledging the stream session, then remember to send the
> files in the snapshot to the unavailable nodes when they come back up. This
> isn't quite ideal since of course the node may have compacted these files,
> however it's much simpler than any sort of key tracking at this scale.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
