[jira] [Commented] (CASSANDRA-5907) Leveled compaction may cause overlap in L1 when L0 compaction get behind
[
https://issues.apache.org/jira/browse/CASSANDRA-5907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13746567#comment-13746567
]
Jeremiah Jordan commented on CASSANDRA-5907:
Reading the patch 10 times, I think that logic is right to skip doing parallel
L0 compactions if there is any overlap.
Leveled compaction may cause overlap in L1 when L0 compaction get behind
Key: CASSANDRA-5907
URL: https://issues.apache.org/jira/browse/CASSANDRA-5907
Project: Cassandra
Issue Type: Bug
Reporter: Yuki Morishita
Assignee: Yuki Morishita
Priority: Minor
Fix For: 1.2.9
Attachments: 5907-1.2.txt
1.2 makes LCS run parallel, though if L0 compaction get far behind and
concurrent compactions at L0 where each compaction holds maximum number of
SSTable to compact at L0(32), it will likely cause overlap in L1. There will
be ERROR log as follows:
{code}
ERROR [CompactionExecutor:30] 2013-08-19 17:54:29,648 LeveledManifest.java
(line 244) At level 1, SSTableReader(path='xxx-Data.db')
[DecoratedKey(204853724659241194183955214890519, 30303132343830),
DecoratedKey(69227335985728660912035125310473966323, 30393537373332)]
overlaps SSTableReader(path='xxx-Data.db')
[DecoratedKey(217896711032704014921095870827202, 30333635363932),
DecoratedKey(71430242198281555888954138354238066233, 30333035343132)]. This
is caused by a bug in Cassandra 1.1.0 .. 1.1.3. Sending back to L0. If you
have not yet run scrub, you should do so since you may also have rows
out-of-order within an sstable
{code}
We should send back compacted SSTables to L0 when compacting max SSTables at
L0. Also, the above error message is confusing, at version 1.2, we can reduce
to WARNing level without mentioning scrub.
C* 2.0 performs Size-Tiered compaction on L0 when it has max SSTables and
sends back compacted SSTable to L0, so I think we don't need to fix this on
2.0.
--
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
[jira] [Commented] (CASSANDRA-5907) Leveled compaction may cause overlap in L1 when L0 compaction get behind
[
https://issues.apache.org/jira/browse/CASSANDRA-5907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13746669#comment-13746669
]
Jonathan Ellis commented on CASSANDRA-5907:
---
+1
NB: I think {{!Sets.intersection(candidates, compacting).isEmpty()}} is
redundant since markCompacting will fail later. Take that out in trunk?
Leveled compaction may cause overlap in L1 when L0 compaction get behind
Key: CASSANDRA-5907
URL: https://issues.apache.org/jira/browse/CASSANDRA-5907
Project: Cassandra
Issue Type: Bug
Reporter: Yuki Morishita
Assignee: Yuki Morishita
Priority: Minor
Fix For: 1.2.9
Attachments: 5907-1.2.txt
1.2 makes LCS run parallel, though if L0 compaction get far behind and
concurrent compactions at L0 where each compaction holds maximum number of
SSTable to compact at L0(32), it will likely cause overlap in L1. There will
be ERROR log as follows:
{code}
ERROR [CompactionExecutor:30] 2013-08-19 17:54:29,648 LeveledManifest.java
(line 244) At level 1, SSTableReader(path='xxx-Data.db')
[DecoratedKey(204853724659241194183955214890519, 30303132343830),
DecoratedKey(69227335985728660912035125310473966323, 30393537373332)]
overlaps SSTableReader(path='xxx-Data.db')
[DecoratedKey(217896711032704014921095870827202, 30333635363932),
DecoratedKey(71430242198281555888954138354238066233, 30333035343132)]. This
is caused by a bug in Cassandra 1.1.0 .. 1.1.3. Sending back to L0. If you
have not yet run scrub, you should do so since you may also have rows
out-of-order within an sstable
{code}
We should send back compacted SSTables to L0 when compacting max SSTables at
L0. Also, the above error message is confusing, at version 1.2, we can reduce
to WARNing level without mentioning scrub.
C* 2.0 performs Size-Tiered compaction on L0 when it has max SSTables and
sends back compacted SSTable to L0, so I think we don't need to fix this on
2.0.
--
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
[jira] [Commented] (CASSANDRA-5907) Leveled compaction may cause overlap in L1 when L0 compaction get behind
[
https://issues.apache.org/jira/browse/CASSANDRA-5907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13745176#comment-13745176
]
Jonathan Ellis commented on CASSANDRA-5907:
---
bq. We should send back compacted SSTables to L0 when compacting max SSTables
at L0
I'm not sure if that's the right solution. Isn't it possible-but-unlikely to
generate the same kind of overlap with non-maxed-out compactions if we happen
to flush the right data at the right time after the first compaction starts?
Leveled compaction may cause overlap in L1 when L0 compaction get behind
Key: CASSANDRA-5907
URL: https://issues.apache.org/jira/browse/CASSANDRA-5907
Project: Cassandra
Issue Type: Bug
Reporter: Yuki Morishita
Assignee: Yuki Morishita
Priority: Minor
Fix For: 1.2.9
1.2 makes LCS run parallel, though if L0 compaction get far behind and
concurrent compactions at L0 where each compaction holds maximum number of
SSTable to compact at L0(32), it will likely cause overlap in L1. There will
be ERROR log as follows:
{code}
ERROR [CompactionExecutor:30] 2013-08-19 17:54:29,648 LeveledManifest.java
(line 244) At level 1, SSTableReader(path='xxx-Data.db')
[DecoratedKey(204853724659241194183955214890519, 30303132343830),
DecoratedKey(69227335985728660912035125310473966323, 30393537373332)]
overlaps SSTableReader(path='xxx-Data.db')
[DecoratedKey(217896711032704014921095870827202, 30333635363932),
DecoratedKey(71430242198281555888954138354238066233, 30333035343132)]. This
is caused by a bug in Cassandra 1.1.0 .. 1.1.3. Sending back to L0. If you
have not yet run scrub, you should do so since you may also have rows
out-of-order within an sstable
{code}
We should send back compacted SSTables to L0 when compacting max SSTables at
L0. Also, the above error message is confusing, at version 1.2, we can reduce
to WARNing level without mentioning scrub.
C* 2.0 performs Size-Tiered compaction on L0 when it has max SSTables and
sends back compacted SSTable to L0, so I think we don't need to fix this on
2.0.
--
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
[jira] [Commented] (CASSANDRA-5907) Leveled compaction may cause overlap in L1 when L0 compaction get behind
[
https://issues.apache.org/jira/browse/CASSANDRA-5907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13745254#comment-13745254
]
Jeremiah Jordan commented on CASSANDRA-5907:
Is this an issue any time L0 compactions happen in parallel? Maybe we should
not allow that?
Leveled compaction may cause overlap in L1 when L0 compaction get behind
Key: CASSANDRA-5907
URL: https://issues.apache.org/jira/browse/CASSANDRA-5907
Project: Cassandra
Issue Type: Bug
Reporter: Yuki Morishita
Assignee: Yuki Morishita
Priority: Minor
Fix For: 1.2.9
1.2 makes LCS run parallel, though if L0 compaction get far behind and
concurrent compactions at L0 where each compaction holds maximum number of
SSTable to compact at L0(32), it will likely cause overlap in L1. There will
be ERROR log as follows:
{code}
ERROR [CompactionExecutor:30] 2013-08-19 17:54:29,648 LeveledManifest.java
(line 244) At level 1, SSTableReader(path='xxx-Data.db')
[DecoratedKey(204853724659241194183955214890519, 30303132343830),
DecoratedKey(69227335985728660912035125310473966323, 30393537373332)]
overlaps SSTableReader(path='xxx-Data.db')
[DecoratedKey(217896711032704014921095870827202, 30333635363932),
DecoratedKey(71430242198281555888954138354238066233, 30333035343132)]. This
is caused by a bug in Cassandra 1.1.0 .. 1.1.3. Sending back to L0. If you
have not yet run scrub, you should do so since you may also have rows
out-of-order within an sstable
{code}
We should send back compacted SSTables to L0 when compacting max SSTables at
L0. Also, the above error message is confusing, at version 1.2, we can reduce
to WARNing level without mentioning scrub.
C* 2.0 performs Size-Tiered compaction on L0 when it has max SSTables and
sends back compacted SSTable to L0, so I think we don't need to fix this on
2.0.
--
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
[jira] [Commented] (CASSANDRA-5907) Leveled compaction may cause overlap in L1 when L0 compaction get behind
[
https://issues.apache.org/jira/browse/CASSANDRA-5907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13745290#comment-13745290
]
Yuki Morishita commented on CASSANDRA-5907:
---
No.
We check overlap with compacting L0 to prevent L1 overlap if L0 does not maxed
out.
(https://github.com/apache/cassandra/blob/cassandra-1.2.8/src/java/org/apache/cassandra/db/compaction/LeveledManifest.java#L534)
So this only likely happen when compaction task with 32 L0 sstables run
concurrently and those sstables have overlap.
Leveled compaction may cause overlap in L1 when L0 compaction get behind
Key: CASSANDRA-5907
URL: https://issues.apache.org/jira/browse/CASSANDRA-5907
Project: Cassandra
Issue Type: Bug
Reporter: Yuki Morishita
Assignee: Yuki Morishita
Priority: Minor
Fix For: 1.2.9
1.2 makes LCS run parallel, though if L0 compaction get far behind and
concurrent compactions at L0 where each compaction holds maximum number of
SSTable to compact at L0(32), it will likely cause overlap in L1. There will
be ERROR log as follows:
{code}
ERROR [CompactionExecutor:30] 2013-08-19 17:54:29,648 LeveledManifest.java
(line 244) At level 1, SSTableReader(path='xxx-Data.db')
[DecoratedKey(204853724659241194183955214890519, 30303132343830),
DecoratedKey(69227335985728660912035125310473966323, 30393537373332)]
overlaps SSTableReader(path='xxx-Data.db')
[DecoratedKey(217896711032704014921095870827202, 30333635363932),
DecoratedKey(71430242198281555888954138354238066233, 30333035343132)]. This
is caused by a bug in Cassandra 1.1.0 .. 1.1.3. Sending back to L0. If you
have not yet run scrub, you should do so since you may also have rows
out-of-order within an sstable
{code}
We should send back compacted SSTables to L0 when compacting max SSTables at
L0. Also, the above error message is confusing, at version 1.2, we can reduce
to WARNing level without mentioning scrub.
C* 2.0 performs Size-Tiered compaction on L0 when it has max SSTables and
sends back compacted SSTable to L0, so I think we don't need to fix this on
2.0.
--
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
[jira] [Commented] (CASSANDRA-5907) Leveled compaction may cause overlap in L1 when L0 compaction get behind
[
https://issues.apache.org/jira/browse/CASSANDRA-5907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13745585#comment-13745585
]
Jonathan Ellis commented on CASSANDRA-5907:
---
Hmm. I don't follow what the linked line has to do with the problem. (Quite
possibly there are multiple problems.) It looks to me like the bug is that the
max-sstables short circuit here
{code}
if (candidates.size() MAX_COMPACTING_L0)
{
// limit to only the MAX_COMPACTING_L0 oldest candidates
candidates = new
HashSetSSTableReader(ageSortedSSTables(candidates).subList(0,
MAX_COMPACTING_L0));
break;
}
{code}
can chop out some of the overlapping stuff from L1 that we added to
{{candidates}} in the previous loop. (In which case it shouldn't be necessary
to have multiple parallel compactions to cause trouble.)
Leveled compaction may cause overlap in L1 when L0 compaction get behind
Key: CASSANDRA-5907
URL: https://issues.apache.org/jira/browse/CASSANDRA-5907
Project: Cassandra
Issue Type: Bug
Reporter: Yuki Morishita
Assignee: Yuki Morishita
Priority: Minor
Fix For: 1.2.9
1.2 makes LCS run parallel, though if L0 compaction get far behind and
concurrent compactions at L0 where each compaction holds maximum number of
SSTable to compact at L0(32), it will likely cause overlap in L1. There will
be ERROR log as follows:
{code}
ERROR [CompactionExecutor:30] 2013-08-19 17:54:29,648 LeveledManifest.java
(line 244) At level 1, SSTableReader(path='xxx-Data.db')
[DecoratedKey(204853724659241194183955214890519, 30303132343830),
DecoratedKey(69227335985728660912035125310473966323, 30393537373332)]
overlaps SSTableReader(path='xxx-Data.db')
[DecoratedKey(217896711032704014921095870827202, 30333635363932),
DecoratedKey(71430242198281555888954138354238066233, 30333035343132)]. This
is caused by a bug in Cassandra 1.1.0 .. 1.1.3. Sending back to L0. If you
have not yet run scrub, you should do so since you may also have rows
out-of-order within an sstable
{code}
We should send back compacted SSTables to L0 when compacting max SSTables at
L0. Also, the above error message is confusing, at version 1.2, we can reduce
to WARNing level without mentioning scrub.
C* 2.0 performs Size-Tiered compaction on L0 when it has max SSTables and
sends back compacted SSTable to L0, so I think we don't need to fix this on
2.0.
--
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
[jira] [Commented] (CASSANDRA-5907) Leveled compaction may cause overlap in L1 when L0 compaction get behind
[
https://issues.apache.org/jira/browse/CASSANDRA-5907?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13745602#comment-13745602
]
Jonathan Ellis commented on CASSANDRA-5907:
---
It looks like the problem then is a race when we are running getCandidatesFor
before a parallel compaction has marked its sources compacting. We synchronize
getCompactionCandidates (caller of getCandidatesFor) but that is not adequate.
Leveled compaction may cause overlap in L1 when L0 compaction get behind
Key: CASSANDRA-5907
URL: https://issues.apache.org/jira/browse/CASSANDRA-5907
Project: Cassandra
Issue Type: Bug
Reporter: Yuki Morishita
Assignee: Yuki Morishita
Priority: Minor
Fix For: 1.2.9
1.2 makes LCS run parallel, though if L0 compaction get far behind and
concurrent compactions at L0 where each compaction holds maximum number of
SSTable to compact at L0(32), it will likely cause overlap in L1. There will
be ERROR log as follows:
{code}
ERROR [CompactionExecutor:30] 2013-08-19 17:54:29,648 LeveledManifest.java
(line 244) At level 1, SSTableReader(path='xxx-Data.db')
[DecoratedKey(204853724659241194183955214890519, 30303132343830),
DecoratedKey(69227335985728660912035125310473966323, 30393537373332)]
overlaps SSTableReader(path='xxx-Data.db')
[DecoratedKey(217896711032704014921095870827202, 30333635363932),
DecoratedKey(71430242198281555888954138354238066233, 30333035343132)]. This
is caused by a bug in Cassandra 1.1.0 .. 1.1.3. Sending back to L0. If you
have not yet run scrub, you should do so since you may also have rows
out-of-order within an sstable
{code}
We should send back compacted SSTables to L0 when compacting max SSTables at
L0. Also, the above error message is confusing, at version 1.2, we can reduce
to WARNing level without mentioning scrub.
C* 2.0 performs Size-Tiered compaction on L0 when it has max SSTables and
sends back compacted SSTable to L0, so I think we don't need to fix this on
2.0.
--
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
