You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Stu Hood (JIRA)" <ji...@apache.org> on 2011/06/04 01:13:47 UTC
[jira] [Issue Comment Edited] (CASSANDRA-2739) Cannot recover
SSTable with version f (current version g) during the node decommission.
[ https://issues.apache.org/jira/browse/CASSANDRA-2739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13044114#comment-13044114 ]
Stu Hood edited comment on CASSANDRA-2739 at 6/3/11 11:12 PM:
--------------------------------------------------------------
bq. I think that we may in fact be fine already since decodeKey / readRowSize / CompactedRow encapsulate the version knowledge we'd need.
The approach I've taken so far for 674 has been to move all datafile reading logic into the iterators ( see CASSANDRA-2576 and CASSANDRA-2629) which allows the index writing and sstable reading to vary by version.
What those _don't_ allow for is recognizing that the datafile for f is compatible with g, such that it can just be renamed on the destination. We might be able to warn and rewrite the file immediately on the destination if we can't just reindex it directly? This is approximately what 2576 does (but only for counters).
was (Author: stuhood):
bq. I think that we may in fact be fine already since decodeKey / readRowSize / CompactedRow encapsulate the version knowledge we'd need.
The approach I've taken so far has been to move all datafile reading logic into the iterators: see CASSANDRA-2576 and CASSANDRA-2629. What those _don't_ allow for is recognizing that the datafile for f is compatible with g, and can just be renamed on the destination.
> Cannot recover SSTable with version f (current version g) during the node decommission.
> ---------------------------------------------------------------------------------------
>
> Key: CASSANDRA-2739
> URL: https://issues.apache.org/jira/browse/CASSANDRA-2739
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 0.8.0
> Environment: centos, cassandra 0.7.4 upgrade to 0.8.0-final.
> Reporter: Dikang Gu
> Labels: decommission, version
>
> I upgrade the 4-nodes cassandra 0.7.4 cluster to 0.8.0-final. Then, I do the bin/nodetool decommission on one node, the decommission hangs there and I got the following errors on other nodes.
> ERROR [Thread-55] 2011-06-03 18:02:03,500 AbstractCassandraDaemon.java (line 113) Fatal exception in thread Thread[Thread-55,5,main]
> java.lang.RuntimeException: Cannot recover SSTable with version f (current version g).
> at org.apache.cassandra.io.sstable.SSTableWriter.createBuilder(SSTableWriter.java:240)
> at org.apache.cassandra.db.CompactionManager.submitSSTableBuild(CompactionManager.java:1088)
> at org.apache.cassandra.streaming.StreamInSession.finished(StreamInSession.java:108)
> at org.apache.cassandra.streaming.IncomingStreamReader.readFile(IncomingStreamReader.java:104)
> at org.apache.cassandra.streaming.IncomingStreamReader.read(IncomingStreamReader.java:61)
> at org.apache.cassandra.net.IncomingTcpConnection.stream(IncomingTcpConnection.java:155)
> at org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:93)
> ERROR [Thread-56] 2011-06-03 18:02:04,285 AbstractCassandraDaemon.java (line 113) Fatal exception in thread Thread[Thread-56,5,main]
> java.lang.RuntimeException: Cannot recover SSTable with version f (current version g).
> at org.apache.cassandra.io.sstable.SSTableWriter.createBuilder(SSTableWriter.java:240)
> at org.apache.cassandra.db.CompactionManager.submitSSTableBuild(CompactionManager.java:1088)
> at org.apache.cassandra.streaming.StreamInSession.finished(StreamInSession.java:108)
> at org.apache.cassandra.streaming.IncomingStreamReader.readFile(IncomingStreamReader.java:104)
> at org.apache.cassandra.streaming.IncomingStreamReader.read(IncomingStreamReader.java:61)
> at org.apache.cassandra.net.IncomingTcpConnection.stream(IncomingTcpConnection.java:155)
> at org.apache.cassandra.net.IncomingTcpConnection.run(IncomingTcpConnection.java:93)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira