Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
Received-SPF: pass (athena.apache.org: domain of sylvain@datastax.com
 designates 209.85.161.172 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <1309947189.11533.6.camel@Avalon>
References: <1309938914.11533.3.camel@Avalon>
	<CAKkz8Q1dVUMAxq5qJxDb=3xAJjP5Wi7TAzEBFew=rSr-nPBT1g@mail.gmail.com>
	<1309947189.11533.6.camel@Avalon>
Date: Wed, 6 Jul 2011 13:21:03 +0200
Message-ID: 
 <CAKkz8Q2uzySDkzJERJSE43q2+MHw2HOTP8YZppTTC-6-rcqL1Q@mail.gmail.com>
Subject: Re: Cannot recover SSTable with version f (current version g)
From: Sylvain Lebresne <sylvain@datastax.com>
To: user@cassandra.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

2011/7/6 H=E9ctor Izquierdo Seliva <izquierdo@strands.com>:
> 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
> =A0 =A0 =A0 =A0at org.apache.cassandra.io.sstable.SSTableWriter
> $RowIndexer.close(SSTableWriter.java:382)
> =A0 =A0 =A0 =A0at org.apache.cassandra.io.sstable.SSTableWriter
> $RowIndexer.index(SSTableWriter.java:370)
> =A0 =A0 =A0 =A0at org.apache.cassandra.io.sstable.SSTableWriter
> $Builder.build(SSTableWriter.java:315)
> =A0 =A0 =A0 =A0at org.apache.cassandra.db.compaction.CompactionManager
> $9.call(CompactionManager.java:1103)
> =A0 =A0 =A0 =A0at org.apache.cassandra.db.compaction.CompactionManager
> $9.call(CompactionManager.java:1094)
> =A0 =A0 =A0 =A0at java.util.concurrent.FutureTask$Sync.innerRun(FutureTas=
k.java:303)
> =A0 =A0 =A0 =A0at java.util.concurrent.FutureTask.run(FutureTask.java:138=
)
> =A0 =A0 =A0 =A0at java.util.concurrent.ThreadPoolExecutor
> $Worker.runTask(ThreadPoolExecutor.java:886)
> =A0 =A0 =A0 =A0at java.util.concurrent.ThreadPoolExecutor
> $Worker.run(ThreadPoolExecutor.java:908)
> =A0 =A0 =A0 =A0at java.lang.Thread.run(Thread.java:662)

That would be a bug. Can you open a ticket with the exact version
you're using and
the circumstance where this happens.

Thanks.

--
Sylvain

>
>
>
> El mi=E9, 06-07-2011 a las 11:22 +0200, Sylvain Lebresne escribi=F3:
>> 2011/7/6 H=E9ctor Izquierdo Seliva <izquierdo@strands.com>:
>> > Hi, i've been struggling to repair my failed node for the past few day=
s,
>> > 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 messa=
ge).
>> 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 be=
en
>> 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 th=
e most
>> efficient in time and investment it will require from you) is probably s=
omething
>> like that: For each of the nodes of the cluster:
>> =A0 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.
>> =A0 2) if all or almost all the big sstables are 'f', then run scrub on
>> that node, that'll
>> be simpler.
>> =A0 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
>> >
>> >
>> >
>> >
>
>
>