I definitely find it surprising that a node which was decommissioned is willing to rejoin a cluster. I can't think of any legitimate scenario where you'd want that, and I'm surprised the node doesn't track that it was decommissioned and refuse to rejoin without at least a -D flag to force it.
Way too easy for a node to get restarted with, for example, a naive service status checker, or a scheduled reboot after a kernel upgrade, or so forth. You may also have been decommissioning the node because of hardware issues, in which case you may also be threatening the stability or performance characteristics of the cluster, and at absolute best you have short term consistency issues, and near-100% overstreaming to get the node decommissioned again. IMO, especially with the threat to unrecoverable consistency violations, this should be a critical bug. On Wed, Feb 11, 2015 at 12:39 PM, Jonathan Haddad <j...@jonhaddad.com> wrote: > And after decreasing your RF (rare but happens) > > On Wed Feb 11 2015 at 11:31:38 AM Robert Coli <rc...@eventbrite.com> > wrote: > >> On Wed, Feb 11, 2015 at 11:20 AM, Jonathan Haddad <j...@jonhaddad.com> >> wrote: >> >>> It could, because the tombstones that mark data deleted may have been >>> removed. There would be nothing that says "this data is gone". >>> >>> If you're worried about it, turn up your gc grace seconds. Also, don't >>> revive nodes back into a cluster with old data sitting on them. >>> >> >> Also, run cleanup after range movements : >> >> https://issues.apache.org/jira/browse/CASSANDRA-7764 >> >> =Rob >> >> >
