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. On Wed Feb 11 2015 at 11:18:19 AM Stefano Ortolani <ostef...@gmail.com> wrote: > Hi Robert, > > it all happened within 30 minutes, so way before the default > gc_grace_second (864000), so I should be fine. > However, this is quite shocking if you ask me. The only possibility of > getting to an inconsistent state only by restarting a node is appalling... > > Can other people confirm that a restart after the gc_grace_seconds passed > would have violated consistency permanently? > > Cheers, > Stefano > > On Wed, Feb 11, 2015 at 10:56 AM, Robert Coli <rc...@eventbrite.com> > wrote: > >> On Tue, Feb 10, 2015 at 9:13 PM, Stefano Ortolani <ostef...@gmail.com> >> wrote: >> >>> I recommissioned a node after decommissioningit. >>> That happened (1) after a successfull decommission (checked), (2) >>> without wiping the data directory on the node, (3) simply by restarting the >>> cassandra service. The node now reports himself healty and up and running >>> >>> Knowing that I issued the "repair" command and patiently waited for its >>> completion, can I assume the cluster, and its internals (replicas, balance >>> between those) to be healthy and "as new"? >>> >> >> Did you recommission before or after gc_grace_seconds passed? If after, >> you have violated consistency in a manner that, in my understanding, one >> cannot recover from. >> >> If before, you're pretty fine. >> >> However this is a longstanding issue that I personally consider a bug : >> >> Your decommissioned node doesn't forget its state. In my opinion, you >> told it to leave the cluster, it should forget everything it knew as a >> member of that cluster. >> >> If you file this behavior as a JIRA bug, please let the list know. >> >> =Rob >> >> >
