You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Jeremiah Jordan (JIRA)" <ji...@apache.org> on 2016/03/15 16:26:33 UTC

[jira] [Commented] (CASSANDRA-11355) Tool to recover orphaned partitions

    [ https://issues.apache.org/jira/browse/CASSANDRA-11355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15195477#comment-15195477 ] 

Jeremiah Jordan commented on CASSANDRA-11355:
---------------------------------------------

Consistent range movement during bootstraps solves this problem in the happy path by streaming the data from the node that you are taking over for, but people disable that at times, and there are always exceptional cases.

Giving cleanup the option to save the data it was going to throw away into a "snapshot" like location sounds like a good idea to me.  A user could then use sstableloader to feed it back into the cluster if they think they lost something.

> Tool to recover orphaned partitions
> -----------------------------------
>
>                 Key: CASSANDRA-11355
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-11355
>             Project: Cassandra
>          Issue Type: Wish
>            Reporter: Devin Suiter
>            Priority: Minor
>
> Sometimes due to interrupted topology changes, nodes forced to join for some reason, or other operations that could shift token ownership, in conjunction with some other poor practices, could leave a situation where a partition replica left on a node that no longer owns it is the only correct replica of that partition.
> Is there value to a nodetool command, or an option to the cleanup command, that would walk through keys left on a node that were outside that node's range, determine the current endpoints, and stream the replicas to the current endpoints if that record is the newest record?
> It seems like repair would ignore those partitions currently, and cleanup simply removes them.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)