Thanks Sylvain. I'll try option 3 when the current repair ends so I can
fix the remaining CFs.
I'm also finding a few of this while opening sstables that have been
build with repair (SSTable build compactions)
ERROR [CompactionExecutor:2] 2011-07-06 10:09:16,054
AbstractCassandraDaemon.java (line 113) Fatal exception in thread
Thread[CompactionExecutor:2,1,main]
java.lang.NullPointerException
at org.apache.cassandra.io.sstable.SSTableWriter
$RowIndexer.close(SSTableWriter.java:382)
at org.apache.cassandra.io.sstable.SSTableWriter
$RowIndexer.index(SSTableWriter.java:370)
at org.apache.cassandra.io.sstable.SSTableWriter
$Builder.build(SSTableWriter.java:315)
at org.apache.cassandra.db.compaction.CompactionManager
$9.call(CompactionManager.java:1103)
at org.apache.cassandra.db.compaction.CompactionManager
$9.call(CompactionManager.java:1094)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor
$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor
$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
El mié, 06-07-2011 a las 11:22 +0200, Sylvain Lebresne escribió:
> 2011/7/6 Héctor Izquierdo Seliva <izquie...@strands.com>:
> > Hi, i've been struggling to repair my failed node for the past few days,
> > and I've seen this erros a few times.
> >
> > java.lang.RuntimeException: Cannot recover SSTable with version f
> > (current version g).
> >
> > If it can read the sstables, why can't they be used to repair?
>
> After a sstable is streamed (by repair in particular), we first have to
> recreate
> a number of data structures. To do that, a specific part of the code is used
> that do not know how to cope with older sstable version (hence the message).
> This does not mean that this won't even get fixed, it will, but it is a
> current
> limitation.
>
> > Is there anything I can do besides running scrub or compact on all the
> > cluster?
>
> Not really no. You can wait enough time so that all old sstables have been
> compacted to newer version before running a repair, but since that could take
> a long time if you have lots of data, that may not always be an option.
> Now probably the most "efficient" way (the quote are because it's not the most
> efficient in time and investment it will require from you) is probably
> something
> like that: For each of the nodes of the cluster:
> 1) look the sstables on the node (do a 'ls' on the data repository).
> The sstable
> will look something like Standard1-g-105-Data.db where the 'g' may be a 'f'
> for
> some (all?) of the sstable. The 'f' means old sstable, the 'g' means new ones.
> 2) if all or almost all the big sstables are 'f', then run scrub on
> that node, that'll
> be simpler.
> 3) if only a handfull of sstable are on 'f' (typically, if the node
> has not just been updated),
> then what you can do is to force a compaction on those only by using
> JMX->CompactionManager->forceUserDefinedCompaction,
> giving it the keyspace name as first argument and the full path to the
> sstable as second
> argument.
>
>
>
> >
> > Regards
> >
> > Hector Izquierdo
> >
> >
> >
> >
