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 > > > >
