[
https://issues.apache.org/jira/browse/CASSANDRA-7446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14169558#comment-14169558
]
Jason Brown commented on CASSANDRA-7446:
----------------------------------------
Hmm, I'm kinda -1 on this, as the coordinator will have no idea who now has
those batchlog entries (after they've been streamed off), so we're pretty much
guaranteed that the new owner of the batchlog entries will replay them. If
anything, maybe the decommissioned node should just ahead and send them.
This being said, in SS.decomission, we already wait RING_DELAY before
performing any unbootstrap() work (and we've already gossiped that we're
leaving). And by the time we've streamed off the data (and the hints) it's most
likely that any batchlog entries we would have been either deleted or replayed
as streaming a non-trivial amount of data will take some amount of time greater
than the batchlog replay timeout.
> Batchlog should be streamed to a different node on decom
> --------------------------------------------------------
>
> Key: CASSANDRA-7446
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7446
> Project: Cassandra
> Issue Type: Bug
> Reporter: Aleksey Yeschenko
> Assignee: Branimir Lambov
>
> Just like we stream hints on decom, we should also stream the contents of the
> batchlog - even though we do replicate the batch to at least two nodes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
