Hi, This was my first thought too, but if you take a look at the logs I > attached to previous e-mail, you'll notice that query "by key" > (no-index.log) retrieves data from BOTH replicas, while the "by indexed > column" one (index.log) talks only to one of them (too bad it's the one > that contains tombstone only - 1:7). In the first case it is possible to > "resolve" the conflict and return the proper result, while in the second > case it's impossible because tombstone is the only thing that is returned > for this key. > Sorry, I did not look into the logs. Thats the first time I'm seeing the trace btw. :-)
Does CQL not allow CL=ONE queries? Why does it ask two nodes for the key, when you say that you are using CL=default=1? I'm a bit confused here (I'm a thrift user). But thinking about your theory some more: I think CASSANDRA-4905 might make reappearing columns more common (only if you do not run repair within gc_grace of course). Before CASSANDRA-4905 the tombstones would be repaired even after gc_grace, so it was a bit more forgiving. It was never guaranteed that the inconsistency would be repaired though. I think you should have increased gc-grace or run repair within the 10 days. The repair bit makes sense now in my head, unlike the CQL CL :-) cheers, Christian
