You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Gary Dusbabek (JIRA)" <ji...@apache.org> on 2010/08/25 22:03:17 UTC
[jira] Issue Comment Edited: (CASSANDRA-1431) Unable to upgrade
0.6.1 to 0.6.4
[ https://issues.apache.org/jira/browse/CASSANDRA-1431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12902605#action_12902605 ]
Gary Dusbabek edited comment on CASSANDRA-1431 at 8/25/10 4:01 PM:
-------------------------------------------------------------------
This is bizarre. The column bloom filter indicates that TOKEN and GENERATION are both present in LocationInfo-19. But the column index is listing a completely bogus firstName that throws the comparator off. The result is that SSTableNamesIterator thinks the columns are not present.
Cassandra realizes it can't read the columns it expects to be there, even though the data files are present, so it promptly exits.
I was able to work around this by forcing a compaction of the system keyspace in 0.6.1 and then upgrading to 0.6.current. The bad index entry stays around, but doesn't create a problem because it becomes the lastName of the index info (doesn't interfere with the comparator with the columns we use).
I'm curious how the bad colname (it's not even valid utf8!) got into the index. I couldn't reproduce with a vanilla 0.6.1 checkout. I wonder it came from an even older version of Cassandra. For the record, the invalid column in the index is 0xc0a8fe0b.
was (Author: gdusbabek):
This is bizarre. The column bloom filter indicates that TOKEN and GENERATION are both present in LocationInfo-19. But the column index is listing a completely bogus firstName that throws the comparator off. The result is that SSTableNamesIterator thinks the columns are not present.
Cassandra realizes it can't read the columns it expects to be there, even though the data files are present, so it promptly exits.
I was able to work around this by forcing a compaction of the system keyspace in 0.6.1 and then upgrading to 0.6.current.
I'm curious how the bad colname (it's not even valid utf8!) got into the index. I couldn't reproduce with a vanilla 0.6.1 checkout. I wonder it came from an even older version of Cassandra. For the record, the invalid column in the index is 0xc0a8fe0b.
> Unable to upgrade 0.6.1 to 0.6.4
> --------------------------------
>
> Key: CASSANDRA-1431
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1431
> Project: Cassandra
> Issue Type: Bug
> Affects Versions: 0.6.4
> Environment: 0.6.1, 0.6.4
> Reporter: Aleksey Pesternikov
> Assignee: Gary Dusbabek
> Attachments: system.tgz
>
>
> I'm trying to upgrade 0.6.1 to 0.6.4 and receive the following error:
> DEBUG 09:45:27,077 Starting CFS LocationInfo
> INFO 09:45:27,240 Sampling index for /data/cassandra/system/LocationInfo-19-Data.db
> DEBUG 09:45:27,292 INDEX LOAD TIME for /data/cassandra/system/LocationInfo-19-Data.db: 104 ms.
> INFO 09:45:27,292 Sampling index for /data/cassandra/system/LocationInfo-20-Data.db
> DEBUG 09:45:27,292 INDEX LOAD TIME for /data/cassandra/system/LocationInfo-20-Data.db: 0 ms.
> DEBUG 09:45:27,292 key cache capacity for LocationInfo is 2
> DEBUG 09:45:27,292 Starting CFS HintsColumnFamily
> INFO 09:45:27,347 Sampling index for /data/cassandra/system/HintsColumnFamily-12-Data.db
> DEBUG 09:45:27,347 INDEX LOAD TIME for /data/cassandra/system/HintsColumnFamily-12-Data.db: 0 ms.
> DEBUG 09:45:27,347 key cache capacity for HintsColumnFamily is 1
> ERROR 09:45:27,347 Fatal exception during initialization
> java.io.IOException: Found system table files, but they couldn't be loaded. Did you change the partitioner?
> at org.apache.cassandra.db.SystemTable.checkHealth(SystemTable.java:154)
> at org.apache.cassandra.thrift.CassandraDaemon.setup(CassandraDaemon.java:94)
> at org.apache.cassandra.thrift.CassandraDaemon.main(CassandraDaemon.java:211)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.