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

本文详细解析了Cassandra启动失败的原因,即SSTable损坏,并提供了通过删除损坏数据和使用nodetool repair进行数据恢复的方法。对于单节点部署,数据丢失风险较高;而集群环境下,可以利用复制特性避免数据损失。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

  最近莫名其妙的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: java.io.DataInputStream@19447b3

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

  

转载于:https://www.cnblogs.com/maheng/p/5001181.html

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值