Cassandra 2.1.5正在Debian 3.2.68-1+deb7u5 x86_64 GNU/Linux
# java -version
java version "1.7.0_72"
Java(TM) SE Runtime Environment (build 1.7.0_72-b14)
Java HotSpot(TM) 64-Bit Server VM (build 24.72-b04, mixed mode)
6个节点的集群。来自客户端的查询正常工作。但磁盘空间使用率为80-90％（对于cassandra数据）。并且大型表的压缩是悬挂的（并且也是清理） - 没有任何错误。直到节点重新启动 - 在小表的压缩工作之后才开始压缩大表（> 50Gb） - 从此时刻“{进程”和“已完成”列中的nodetool compactionstats不会更改并递增“待处理任务” ”
nodetool stop COMPACTION
没有解决这个问题：检查 - cassandra在这一刻做了什么？从压缩中仅跳过大表？ 加入新的节点，比如压缩，就会挂起......
答案 0 :(得分：0)
我们的 2.1.5 cassandra 集群 4 个节点也面临类似的情况。没有错误，但压缩被卡住，节点无法处理传入的请求。我们使用 jstack 进行线程转储，然后找到挂起的压缩线程。然后，我们杀了它。之后，节点照常工作。