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