cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-6434) Repair-aware gc grace period
Date Wed, 08 Jul 2015 14:59:05 GMT


Sylvain Lebresne commented on CASSANDRA-6434:

Ok, so as I said above, I'm not really a fan of keeping for every tombstone if it's from a
repaired or unrepaired sstable. Tombstones do not necessarily originate from a sstable, and
so putting this information everywhere is confusing and more complex/widely impactful than
it should be.

Now, as you said, the only problem is the read path. Couldn't we use a non-optimal (but much
simpler and hopefully good enough) solution for that? Typically, unrepaired sstables should,
by design, be fairly recent. So what if we said that we only purge tombstone if it's older
than gcGrace *and* its {{localDeletionTime}} is older than then oldest {{localDeletion}} in
the unrepaired sstables used by the query? We'll be guaranteed to only purge tombstone from
repaired sstables, and while we might include a few tombstones from repaired sstables that
we shouldn't, that's unlikely to be a whole lot (and it's technically ok to do so anyway),
and is probably not a big price to pay for the extra safety.

> Repair-aware gc grace period 
> -----------------------------
>                 Key: CASSANDRA-6434
>                 URL:
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: Core
>            Reporter: sankalp kohli
>            Assignee: Marcus Eriksson
>             Fix For: 3.0 beta 1
> Since the reason for gcgs is to ensure that we don't purge tombstones until every replica
has been notified, it's redundant in a world where we're tracking repair times per sstable
(and repairing frequentily), i.e., a world where we default to incremental repair a la CASSANDRA-5351.

This message was sent by Atlassian JIRA

View raw message