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, 11 Nov 2014 08:44:34 GMT


Marcus Eriksson commented on CASSANDRA-6434:

Hint TTL is set to the smallest gcgs among the column families included in the mutation to
make sure we don't resurrect any data by replaying an old hint.

After this ticket we would only drop tombstones if the sstable is repaired, repairing the
node will also make sure that it has received the data it should have. If we then receive
a hint for a range that is from before the last repair, we could safely ignore it. CL.ANY
makes this more unclean since a node might not actually have all the data it should after
a repair, but, if we keep a safety window of max_hint_window_in_ms during which we always
keep the tombstones, repaired or not, we would probably be safe. (and it would solve [~jjordan]s
issue above as well)

I most likely missed/ignored some corner case (like that last comment on CASSANDRA-3620 and
batches generating new hints etc.. rage)

> 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