cassandra启动失败——cassandra总结(四)

　　最近莫名其妙的cassandra不能启动了，查看登录日志后终于找到了原因。(登录日志位于与$CASSANDRA_HOME同级目录的cassandra文件夹中)

　　先看下错误报告

ERROR [SSTableBatchOpen:2] 2015-11-26 21:59:06,933 FileUtils.java:447 - Exiting forcefully due to file system exception on startup, disk failure policy "stop"
org.apache.cassandra.io.FSReadError: java.io.IOException: Compressed file with 0 chunks encountered: [email protected]

　　SSTable打开失败，原因是SSTable损坏了，看下老外的说法

Having some replication would surely help you to fix this without data loss but it would come with a price.

Despite all your effort you cannot manage to recover your corrupted sstable. So you decide to remove it from your file system to start Cassandra again. If you do not have replication your data is lost. But if you have replication on the cluster, you can possibly fetch the data from other nodes. That is what nodetool repair do !

So nodetool repair does not repair corrupted sstable. Basicallynodetool repair compare tables from node to node to find missing or inconsistent data and then repair it. You can find more information on how it works here.

However nodetool repair is very expensive, it is long and uses a lot of cpu, disk and network. There is this good post about repair benefits and drawbacks.

　　遇到SSTable损坏这种问题解决办法就是删掉数据然后重启cassandra，由于我采用的单节点所以数据自然就没有备份了，很坑的说，不过好在只有几万条分析数据，再插入进去就好了。如果是集群的话就可以用nodetool repair从别的节点把备份数据取过来了，但是代价很大，会花费大量的时间，占用大量的CPU。所以最好还是做好备份了。

　　在删除掉数据重启后，轻松启动成功。启动成功日志文件的最后一行表现是：

INFO  [Thread-2] 2015-11-27 16:30:52,550 ThriftServer.java:136 - Listening for thrift clients...