[
https://issues.apache.org/jira/browse/CASSANDRA-4905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13666542#comment-13666542
]
Michael Theroux commented on CASSANDRA-4905:
--------------------------------------------
We have a large variety of usecases that have different table characteristics.
We do have tables with wide rows, and do have tables with ttls, but don't have
tables with wide rows and ttls together.
Nodetool ring shows we have 280GB per node, or a little less.
If I'm understanding the issue though, all you would need is large numbers of
tombstones getting compacted and deleted from one node, and not the others.
The table that has been giving us the most grief uses LeveledCompaction, which
makes a guarantee that at most 10% of space will be wasted by obsolete rows.
Given that there is no guarantee that the 10% of rows on one node overlaps with
the 10% of rows on another node, could it be possible that this causes the
massive repairs?
> Repair should exclude gcable tombstones from merkle-tree computation
> --------------------------------------------------------------------
>
> Key: CASSANDRA-4905
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4905
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Christian Spriegel
> Assignee: Sylvain Lebresne
> Fix For: 1.2.0 beta 3
>
> Attachments: 4905.txt
>
>
> Currently gcable tombstones get repaired if some replicas compacted already,
> but some are not compacted.
> This could be avoided by ignoring all gcable tombstones during merkle tree
> calculation.
> This was discussed with Sylvain on the mailing list:
> http://cassandra-user-incubator-apache-org.3065146.n2.nabble.com/repair-compaction-and-tombstone-rows-td7583481.html
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
