因为cassandra日志提示文件损坏,尝试过repair命令修复,可是卡着不动
于是kill -9后,又尝试用nodetool scrub丢弃损坏数据
到现在跑了一夜了,还没完,看cassandra日志也看不出东西,目前是控制不让数据写入
另外在执行期间为什么在13(DataC)上看12(DataB)是Down的,但是在11、12上看都是Up的
补上nodetool compactionstats
的图,三个节点都差不多
根据您提供的信息,可能的原因和建议如下:
Cassandra日志提示文件损坏,尝试过Repair命令修复,但进度非常缓慢。
可能是文件损坏的范围比较大,导致修复速度非常缓慢。建议您考虑更换硬盘或者节点,以避免数据持续损坏的风险。
执行nodetool scrub丢弃损坏数据操作,耗时较长。
nodetool scrub的过程会检查并删除损坏的数据,如果数据比较多的话,时间会比较长。您可以通过监控nodetool scrub的运行状况,观察IO和CPU的占用情况,来确认操作是否仍在进行中。如果操作没有被卡死,可以等待操作完成,操作完成后Cassandra会自动恢复数据写入。
在执行nodetool scrub过程中,在一些节点上DataB被标记为Down状态,但在其他节点上是Up状态。
这可能是因为DataB节点上的数据损坏程度较为严重,导致其他节点无法从DataB节点上读取到数据,进而将DataB标记为Down状态。建议您尝试在DataB所在的节点上查看Cassandra的日志,以确认数据损坏的程度和影响范围。
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。
阿里云NoSQL数据库提供了一种灵活的数据存储方式,可以支持各种数据模型,包括文档型、图型、列型和键值型。此外,它还提供了一种分布式的数据处理方式,可以支持高可用性和容灾备份。包含Redis社区版和Tair、多模数据库 Lindorm、MongoDB 版。