cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From aaron morton <>
Subject Re: unrepairable sstable data rows
Date Mon, 11 Apr 2011 20:58:39 GMT
FYI, I was chatting with Dominic Williams on IRC yesterday, he had an 0.7.4 install with the
same problem see error stack here 

He has not run nodetool scrub but I think it the 0.7.4 install had been there a while so I
the data file may have been fresh. 


On 11 Apr 2011, at 22:30, Sylvain Lebresne wrote:

> Remove main-f-5-{Index|Filter|Statistics}.db files. They make no sense
> without a Data file and
> Cassandra always make sure it removes those before the Data file (that
> while it gets confused if it
> finds one of those file without a data file).
> Note that your error was with the sstable main-f-232-Data.db, so it
> would probably have been enough
> to remove only main-f-232* (while it seems you have also removed
> main-f-5-Data.db). I fear its probably
> too late (it will just be potentially much more data to repair than necessary).
> Out of curiosity, what version of Cassandra are you running ?
> --
> Sylvain
> On Mon, Apr 11, 2011 at 12:08 PM, Jonathan Colby
> <> wrote:
>> Thanks for the answer Aaron.
>> There are Data, Index, Filter, and Statistics files associated with SSTables.   What
files must be physically moved/deleted?
>> I tried just moving the Data file and Cassandra would not start. I see this exception:
>>  WARN [WrapperSimpleAppMain] 2011-04-11 12:04:23,239 (line
493) Removing orphans for /var/lib/cassandra/data/DFS/main-f-5: [Data.db]
>> ERROR [WrapperSimpleAppMain] 2011-04-11 12:04:23,240
(line 333) Exception encountered during startup.
>> java.lang.AssertionError: attempted to delete non-existing file main-f-5-Data.db
>>        at
>>        at
       at org.apache.cassandra.db.ColumnFamilyStore.scrubDataDirectories(
>>        at org.apache.cassandra.service.AbstractCassandraDaemon.setup(
>> On Apr 11, 2011, at 2:14 AM, aaron morton wrote:
>>> But if you wanted to get fresh data on the node, a simple approach is to delete/move
just the SSTable that is causing problems then run a repair. That should reduce the amount
of data that needs to be moved.

View raw message