cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brandon Williams (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-5459) Remove node from seeds list when it permanently leaves the cluster
Date Fri, 12 Apr 2013 15:18:19 GMT

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

Brandon Williams commented on CASSANDRA-5459:
---------------------------------------------

Why do we reload the seeds from DD?
                
> Remove node from seeds list when it permanently leaves the cluster
> ------------------------------------------------------------------
>
>                 Key: CASSANDRA-5459
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-5459
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>    Affects Versions: 1.1.10, 1.2.4, 2.0
>            Reporter: Jason Brown
>            Assignee: Jason Brown
>            Priority: Minor
>              Labels: gossip, seeds
>             Fix For: 1.1.11, 1.2.5, 2.0
>
>         Attachments: 5459-v1.patch
>
>
> When a node leaves the cluster for good (via removetoken, decommission, or is replaced
via replace_token), we clean up all references to it in MS and Gossiper. However, we never
remove the entry from the seeds list in Gossiper (if the node was a seed). This will cause
Gossiper to still try to communicate with the removed node as we try to talk to a random seed
on each round of gossip.
> The attached patch will remove the node from seed list when it leaves the cluster, and
further, will call the SeedProvider for an updated list of seeds. In a dynamic environment
like EC2, when a node dies or is replaced, that node is never coming back. Thus is it advantageous
to get a refreshed set of seeds to help with the network partition healing aspect of gossip
(we dynamically retrieve that list in Priam). This makes seeds a bit more of a dynamic concept,
but it's rather essential in a dynamic cloud environment.
> I believe this also resolves that repeated log message like :
> {code}Nodes /10.217.XXX.YYY and /10.217.AAA.BBB have the same token 56713727820156410577229101240436610841.
 Ignoring /10.217.XXX.YYY{code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message