[ 
https://issues.apache.org/jira/browse/CASSANDRA-6434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14206162#comment-14206162
 ] 

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: https://issues.apache.org/jira/browse/CASSANDRA-6434
>             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
(v6.3.4#6332)

Reply via email to