Definitely, I think the very same re this issue. On Thu, Feb 12, 2015 at 7:04 AM, Eric Stevens <migh...@gmail.com> wrote:
> 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 >>> >>> >> >
