cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From horschi <>
Subject Re: Repair does not fix inconsistency
Date Thu, 04 Apr 2013 12:04:10 GMT

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 :-)


View raw message