SSTable generation clash during compaction
------------------------------------------
Key: CASSANDRA-418
URL: https://issues.apache.org/jira/browse/CASSANDRA-418
Project: Cassandra
Issue Type: Bug
Affects Versions: 0.5
Reporter: Sammy Yu
Assignee: Sammy Yu
Fix For: 0.5
We found that one of our node started getting timeouts for get_slice. Looking
further we found that the CFS.ssTables_ references a SStable doesn't exist on
the file system.
Walking down the log we see that the sstable in question 6038 is being
compacted onto itself (in terms of filename file wise it is written to -tmp):
system.log.2009-09-01: INFO [MINOR-COMPACTION-POOL:1] 2009-09-01 23:50:07,553
ColumnFamilyStore.java (line 1067) Compacting
[/mnt/var/cassandra/data/Digg/FriendActions-6037-Data.db,/mnt/var/cassandra/data/Digg/FriendActions-6038-Data.db,/mnt/var/cassandra/data/Digg/
FriendActions-6040-Data.db,/mnt/var/cassandra/data/Digg/FriendActions-6042-Data.db]
system.log.2009-09-01: INFO [MINOR-COMPACTION-POOL:1] 2009-09-01 23:51:43,727
ColumnFamilyStore.java (line 1209) Compacted to
/mnt/var/cassandra/data/Digg/FriendActions-6038-Data.db. 0/1010269806 bytes
for 9482/9373 keys read/written. Time: 96173ms.
It appears the generation number is generated by looking at the lowest number
in the list of files to be compacted and adding 1. In this scenario it is
6037+1=6038.
The code in CFS.doFileCompaction will remove the key and add the key back and
remove the key again, hence the error we were seeing.
Should the generation number be generated via another way or should we update
doFileCompaction to be smarter?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
