[
https://issues.apache.org/jira/browse/CASSANDRA-5780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14133061#comment-14133061
]
Robert Coli edited comment on CASSANDRA-5780 at 9/14/14 3:08 AM:
-----------------------------------------------------------------
For the record, I continue to assert that the correct thing to do in this case
is to truncate the system column family. If one needs to do forensic analysis
of previous node state, one can sstable2json the SSTables from the snapshot
which results. There are cases where the retained information is dangerous, and
few cases where one actually needs or wants to retain it *as live node state*.
tl;dr - "Decommission should mean decommission." :D
was (Author: rcoli):
For the record, I continue to assert that the correct thing to do in this case
is to truncate the system column family. If one needs to do forensic analysis
of previous node state, one can sstable2json the SSTables from the snapshot
which results. There are cases where the retained information is dangerous, and
few cases where one actually needs or wants retain it *as live node state*.
tl;dr - "Decommission should mean decommission." :D
> 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.0.11
>
>
> 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)
