cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Theroux (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-4905) Repair should exclude gcable tombstones from merkle-tree computation
Date Thu, 11 Apr 2013 20:05:16 GMT

    [ 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

Mime
View raw message