cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Coli <rc...@palominodb.com>
Subject Re: repair, compaction, and tombstone rows
Date Fri, 02 Nov 2012 16:39:00 GMT
On Fri, Nov 2, 2012 at 2:46 AM, horschi <horschi@gmail.com> wrote:
> might I ask why repair cannot simply ignore anything that is older than
> gc-grace? (like Aaron proposed)  I agree that repair should not process any
> tombstones or anything. But in my mind it sounds reasonable to make repair
> ignore timed-out data. Because the timestamp is created on the client, there
> is no reason to repair these, right?

IIRC, tombstone timestamps are written by the server, at compaction
time. Therefore if you have RF=X, you have X different timestamps
relative to GCGraceSeconds. I believe there was another thread about
two weeks ago in which Sylvain detailed the problems with what you are
proposing, when someone else asked approximately the same question.

> I even noticed an increase when running two repairs directly after each
> other. So even when data was just repaired, there is still data being
> transferred. I assume this is due some columns timing out within that
> timeframe and the entire row being repaired.

Merkle trees are an optimization, what they trade for this
optimization is over-repair.

(FWIW, I agree that, if possible, this particular case of over-repair
would be nice to eliminate.)

=Rob

-- 
=Robert Coli
AIM&GTALK - rcoli@palominodb.com
YAHOO - rcoli.palominob
SKYPE - rcoli_palominodb

Mime
View raw message