[ https://issues.apache.org/jira/browse/CASSANDRA-4905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13629279#comment-13629279 ]
Michael Theroux edited comment on CASSANDRA-4905 at 4/11/13 8:04 PM: --------------------------------------------------------------------- I believe we are hitting a situation where this bug is being problematic in 1.1.9. We have a column family, for historical reasons, we run staggered major compactions on. This column family also has many deletes. We've noticed our bloom filters increasing in size by an amount over time. Bloom filters on a specific node would go down a great deal after a major compaction, only to increase back to near their original level over a few days. What I believe is happening is we had a staggered repair schedule, along with a staggered major compaction schedule. The major compaction would remove the tombstones, but the repair would stream them back. To test the theory, I adjusted the major compaction schedule to perform a major compaction across all nodes on the same day. This weeks behavior and bloom filter growth has been much better. Is there a reason why this patch was not applied to 1.1.X? Are there stability concerns? We aren't ready to make the jump to 1.2, and would prefer not to move this table to Leveled Compaction if we don't have to. was (Author: mtheroux2): I believe we are hitting a situation where this bug is being problematic in 1.1.9. We have a column family, for historical reasons, we run staggered major compactions on. This column family also has many deletes. We've noticed our bloom filters increasing in size by an amount over time. Bloom filters on a specific node would go down a great deal after a major compaction, only to increase back to near their original level over a few days. What I believe is happening is we had a staggered repair schedule, along with a staggered major compaction schedule. The major compaction would remove the tombstones, but the repair would stream them back. To test the theory, I adjusted the major compaction schedule to perform a major compaction across all nodes on the same day. This weeks behavior and bloom filter growth has been much better. Is there a reason why this patch was not applied to 1.1.X? Are their stability concerns? We aren't ready to make the jump to 1.2, and would prefer not to move this table to Leveled Compaction if we don't have to. > 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