cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcus Eriksson (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-6434) Repair-aware gc grace period
Date Tue, 22 Jul 2014 09:36:38 GMT


Marcus Eriksson commented on CASSANDRA-6434:

Hmm yes, [~kohlisankalp]s approach of dropping tombstones immediately (if the key is not in
any other sstable) works during compaction since we never compact repaired and unrepaired
data together. When doing incremental repair we should probably include all tombstones. It
is during reads we need an actual value on gcBefore.

bq. We could approximate it as max(repairtime) for any sstable that may contain the key.
Unless I misunderstand your suggestion, I don't think that would work since max(repairtime)
is dependent on compaction - the resulting sstable gets the worst case (oldest) repair time
among the involved sstables, meaning different nodes will disagree on when the last repair
was done for a key.

I'll unlink CASSANDRA-5839 - it would not work looking up actual per-key repair times during
reads anyway. Lets use gcgs on unrepaired data until we always mark sstables as repaired.

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