[
https://issues.apache.org/jira/browse/CASSANDRA-435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jaakko Laine updated CASSANDRA-435:
-----------------------------------
Attachment: 435-modify-update_leaving_ranges.txt
I think updateLeavingRanges should do:
(1) get all ranges the leaving is currently storing
(2) get current natural endpoints for those ranges
(3) get natural endpoints for these ranges when leaving node is removed
(4) compare these two lists and add pending ranges for all nodes that are new
in the lists (that is, taking responsibility for these ranges now that one node
is leaving).
I think we need to do this through replication strategy as by simply looking at
token list we cannot deduce what other constraints need to be satisfied. The
replica list might change by more than one node if rack awareness (or other
external considerations) are taken into account.
> unbootstrap
> -----------
>
> Key: CASSANDRA-435
> URL: https://issues.apache.org/jira/browse/CASSANDRA-435
> Project: Cassandra
> Issue Type: New Feature
> Reporter: Jonathan Ellis
> Assignee: Jonathan Ellis
> Fix For: 0.5
>
> Attachments:
> 0001-CASSANDRA-435-clean-up-transfer-code-from-BMVH-move-t.txt,
> 0002-move-more-generic-streaming-code-into-Streaming.java.txt,
> 0003-r-m-unused-bootstrap-directory.txt, 0004-add-leaving-mode.txt,
> 435-0.diff, 435-modify-update_leaving_ranges.txt
>
>
> add JMX command to tell a node to decommission itself (moving its data to the
> next node on the ring)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
