[ https://issues.apache.org/jira/browse/CASSANDRA-8801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14339047#comment-14339047 ]
Brandon Williams commented on CASSANDRA-8801: --------------------------------------------- Cassandra has had this behavior since the inception of decom, and it has saved more people who accidentally issue a decom against the wrong node than it has bitten. That said I agree with your recommendation to remember decommissioning and requiring a -D flag to rejoin. > Decommissioned nodes are willing to rejoin the cluster if restarted > ------------------------------------------------------------------- > > Key: CASSANDRA-8801 > URL: https://issues.apache.org/jira/browse/CASSANDRA-8801 > Project: Cassandra > Issue Type: Bug > Components: Core > Reporter: Eric Stevens > Assignee: Brandon Williams > Fix For: 3.0 > > > This issue comes from the Cassandra user group. > If a node which was successfully decommissioned gets restarted with its data > directory in tact, it will rejoin the cluster immediately going to {{UN}} and > beginning to serve client requests. > This is wrong - the node has consistency issues, having missed any writes > while it was offline because no hinted handoffs were being kept. And in the > best case scenario (it's spotted and remediated immediately), near-100% > overstreaming will still occur. > Also, whatever reasons the operator had for decommissioning the node would > presumably still be valid, so this action may threaten cluster stability if > the node is underpowered or suffering hardware issues. > But what elevates this to critical is that if the node had been offline > longer than gc_grace_seconds, it may cause permanent and unrecoverable > consistency issues due to data resurrection. > h3. Recommendation: > A node should remember that it was decommissioned and refuse to rejoin a > cluster without at least a -Dflag forcing it to. -- This message was sent by Atlassian JIRA (v6.3.4#6332)