[jira] [Updated] (CASSANDRA-6851) Improve anticompaction after incremental repair
[ https://issues.apache.org/jira/browse/CASSANDRA-6851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-6851: --- Fix Version/s: (was: 2.1.1) 3.0 > Improve anticompaction after incremental repair > --- > > Key: CASSANDRA-6851 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6851 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Marcus Eriksson >Assignee: Russell Alexander Spitzer >Priority: Minor > Labels: compaction, lhf > Fix For: 3.0 > > > After an incremental repair we iterate over all sstables and split them in > two parts, one containing the repaired data and one the unrepaired. We could > in theory double the number of sstables on a node. > To avoid this we could make anticompaction also do a compaction, for example, > if we are to anticompact 10 sstables, we could anticompact those to 2. > Note that we need to avoid creating too big sstables though, if we > anticompact all sstables on a node it would essentially be a major compaction. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CASSANDRA-6851) Improve anticompaction after incremental repair
[ https://issues.apache.org/jira/browse/CASSANDRA-6851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-6851: -- Reviewer: Marcus Eriksson Component/s: Core Assignee: Russell Alexander Spitzer > Improve anticompaction after incremental repair > --- > > Key: CASSANDRA-6851 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6851 > Project: Cassandra > Issue Type: Improvement > Components: Core >Reporter: Marcus Eriksson >Assignee: Russell Alexander Spitzer >Priority: Minor > Labels: compaction, lhf > Fix For: 2.1.1 > > > After an incremental repair we iterate over all sstables and split them in > two parts, one containing the repaired data and one the unrepaired. We could > in theory double the number of sstables on a node. > To avoid this we could make anticompaction also do a compaction, for example, > if we are to anticompact 10 sstables, we could anticompact those to 2. > Note that we need to avoid creating too big sstables though, if we > anticompact all sstables on a node it would essentially be a major compaction. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CASSANDRA-6851) Improve anticompaction after incremental repair
[ https://issues.apache.org/jira/browse/CASSANDRA-6851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jonathan Ellis updated CASSANDRA-6851: -- Fix Version/s: (was: 2.1 rc1) 2.1.1 > Improve anticompaction after incremental repair > --- > > Key: CASSANDRA-6851 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6851 > Project: Cassandra > Issue Type: Improvement >Reporter: Marcus Eriksson >Priority: Minor > Labels: compaction, lhf > Fix For: 2.1.1 > > > After an incremental repair we iterate over all sstables and split them in > two parts, one containing the repaired data and one the unrepaired. We could > in theory double the number of sstables on a node. > To avoid this we could make anticompaction also do a compaction, for example, > if we are to anticompact 10 sstables, we could anticompact those to 2. > Note that we need to avoid creating too big sstables though, if we > anticompact all sstables on a node it would essentially be a major compaction. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CASSANDRA-6851) Improve anticompaction after incremental repair
[ https://issues.apache.org/jira/browse/CASSANDRA-6851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcus Eriksson updated CASSANDRA-6851: --- Labels: compaction lhf (was: ) > Improve anticompaction after incremental repair > --- > > Key: CASSANDRA-6851 > URL: https://issues.apache.org/jira/browse/CASSANDRA-6851 > Project: Cassandra > Issue Type: Improvement >Reporter: Marcus Eriksson >Priority: Minor > Labels: compaction, lhf > Fix For: 2.1 beta2 > > > After an incremental repair we iterate over all sstables and split them in > two parts, one containing the repaired data and one the unrepaired. We could > in theory double the number of sstables on a node. > To avoid this we could make anticompaction also do a compaction, for example, > if we are to anticompact 10 sstables, we could anticompact those to 2. > Note that we need to avoid creating too big sstables though, if we > anticompact all sstables on a node it would essentially be a major compaction. -- This message was sent by Atlassian JIRA (v6.2#6252)
