[
https://issues.apache.org/jira/browse/CASSANDRA-10535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14960631#comment-14960631
]
Brandon Williams commented on CASSANDRA-10535:
----------------------------------------------
1) sounds like something for opscenter, not nodetool
2) we tried this in CASSANDRA-4061 and ultimately decommission would have to be
almost completely re-engineered for this, which isn't really worth the effort.
Operators ultimately have to know what they're doing, they can just as easily
drain, kill -9, or rm -rf the incorrect node. At least with decom if you catch
it in time you can just restart the node, and if you don't you're only down one
node and can re-bootstrap it.
> Solidify use of Demmission command
> ----------------------------------
>
> Key: CASSANDRA-10535
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10535
> Project: Cassandra
> Issue Type: Improvement
> Components: Tools
> Environment: All C* environments
> Reporter: Richard Lewis
> Fix For: 3.x, 2.1.x
>
>
> Decommission should have protection mechanisms so nodes are not accidentally
> removed from a cluster due to error input.
> 1) Decommission should have a validation message "Do you really want to do
> this"
> 2) Decommission should be run from a remote node.
> Background, user was on the wrong node, ran decommission, which required no
> validation which resulted in the node being removed from the cluster
> accidentally. There should be validation required so a critical command such
> as this is not accidentally run.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
