cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sammy Yu (JIRA)" <j...@apache.org>
Subject [jira] Updated: (CASSANDRA-418) SSTable generation clash during compaction
Date Thu, 03 Sep 2009 13:52:57 GMT

     [ https://issues.apache.org/jira/browse/CASSANDRA-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Sammy Yu updated CASSANDRA-418:
-------------------------------

    Attachment: 0002-CASSANDRA-418-Use-monotonically-increasing-generatio.patch

Self contained patch that now increment the generation number by one


> SSTable generation clash during compaction
> ------------------------------------------
>
>                 Key: CASSANDRA-418
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-418
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 0.4
>            Reporter: Sammy Yu
>            Assignee: Sammy Yu
>             Fix For: 0.4
>
>         Attachments: 0001-CASSANDRA-418-Use-monotonically-increasing-generatio.patch,
0002-CASSANDRA-418-Use-monotonically-increasing-generatio.patch
>
>
> 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.


Mime
View raw message