Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Wed, 29 Apr 2015 13:12:07 +0000 (UTC)
From: "Carl Yeksigian (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12774914.1423839838000.21141.1430313127748@Atlassian.JIRA>
In-Reply-To: <JIRA.12774914.1423839838000@Atlassian.JIRA>
References: <JIRA.12774914.1423839838000@Atlassian.JIRA>
 <JIRA.12774914.1423839838050@arcas>
Subject: [jira] [Updated] (CASSANDRA-8801) Decommissioned nodes are willing
 to rejoin the cluster if restarted
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/CASSANDRA-8801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Carl Yeksigian updated CASSANDRA-8801:
--------------------------------------
    Reviewer: Carl Yeksigian  (was: Tyler Hobbs)

> 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
>
>         Attachments: 8801.txt
>
>
> 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)