cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Gerlt (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-5780) nodetool status and ring report incorrect/stale information after decommission
Date Sat, 19 Sep 2015 02:50:04 GMT

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

Chris Gerlt commented on CASSANDRA-5780:
----------------------------------------

Thought I would throw a "fresh perspective" on this since I'm relatively new to cassandra,
but it seems to me that when a node is decommissioned, there should be no chance it could
come back appearing as part of the cluster.  Based on that, truncate system seems logical
and safe when you are trying to ensure it does not appear as part of the cluster once decommissioned.
 Also, if the data directory is not altered in anyway, I wonder if there is a concern there,
too?  Hope that helps.

> nodetool status and ring report incorrect/stale information after decommission
> ------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-5780
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-5780
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Tools
>            Reporter: Peter Haggerty
>            Priority: Trivial
>              Labels: lhf, ponies, qa-resolved
>             Fix For: 2.1.x
>
>
> Cassandra 1.2.6 ring of 12 instances, each with 256 tokens.
> Decommission 3 of the 12 nodes, one after another resulting a 9 instance ring.
> The 9 instances of cassandra that are in the ring all correctly report nodetool status
information for the ring and have the same data.
> After the first node is decommissioned:
> "nodetool status" on "decommissioned-1st" reports 11 nodes
> After the second node is decommissioned:
> "nodetool status" on "decommissioned-1st" reports 11 nodes
> "nodetool status" on "decommissioned-2nd" reports 10 nodes
> After the second node is decommissioned:
> "nodetool status" on "decommissioned-1st" reports 11 nodes
> "nodetool status" on "decommissioned-2nd" reports 10 nodes
> "nodetool status" on "decommissioned-3rd" reports 9 nodes
> The storage load information is similarly stale on the various decommissioned nodes.
The nodetool status and ring commands continue to return information as if they were part
of a cluster and they appear to return the last information that they saw.
> In contrast the nodetool info command fails with an exception, which isn't ideal but
at least indicates that there was a failure rather than returning stale information.



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

Mime
View raw message