cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jaakko Laine (JIRA)" <j...@apache.org>
Subject [jira] Updated: (CASSANDRA-435) unbootstrap
Date Tue, 10 Nov 2009 13:47:27 GMT

     [ 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.


Mime
View raw message