Cassandra集群Nodetool status显示已用空间异常问题求助

首先得说，你遇到的这个问题在Cassandra 3.0.x早期版本里真的挺常见的——尤其是当有大量表删除操作时，nodetool status显示的已用空间会和实际磁盘使用量严重脱节，甚至无限增长直到节点挂掉。结合你的集群配置（12节点JBOD、默认压缩策略、定期删表），我来拆解下原因和解决办法：

核心原因分析 #

• SSTable删除后的统计逻辑bug：Cassandra用SSTable存储数据，当你删除表或者大量数据时，这些SSTable会被标记为待删除，但默认的SizeTieredCompactionStrategy（STCS）不会立刻清理它们，而是等合并周期。但3.0.14版本里有个已知问题：nodetool status计算已用空间时，会把已经标记为待删除、甚至已经被删除的SSTable空间依然算进去，因为元数据缓存没有及时更新。
• JBOD模式下的磁盘统计漏洞：JBOD多磁盘配置时，节点对各个磁盘的空间统计没有实时同步，当某个磁盘上的SSTable被清理后，全局的已用空间统计没有跟着调整，导致数值一直累加。
• 统计信息缓存未失效：3.0.14里节点的空间统计是存在缓存里的，删除操作触发后缓存不会自动失效，所以nodetool一直读旧数据，只有重启节点才会重新计算。

临时缓解方案（不用升级版本） #

• 针对性执行nodetool cleanup：对于已经超出保留期删除的表，在每个节点上执行 nodetool cleanup <你的keyspace.表名>，这个命令会清理节点上不属于自己Token范围的SSTable（包括已删表的残留文件），执行完后再看nodetool status，数值应该会回落。注意要在业务低峰期做，而且不要同时在多个节点执行，避免IO过载。
• 刷新元数据缓存：执行 nodetool refresh，这个命令会让节点重新扫描磁盘上的SSTable元数据，不用重启就能刷新空间统计，有时候能直接修正错误数值。
• 滚动重启节点：你现在已经在这么做了，重启会清空统计缓存，节点重启后会重新计算实际已用空间，这是最直接的临时修复方式，适合紧急情况。

长期根治方案 #

• 升级Cassandra版本：3.0.x系列后续的稳定版（比如3.0.26及以后）修复了多个空间统计相关的bug，尤其是删除操作后的元数据更新逻辑。如果业务允许，优先升级到较新的3.0版本；如果有条件，直接升级到4.x版本（不过要提前评估业务兼容性和数据迁移成本）。
• 切换压缩策略：如果你的场景有大量定期删表/删数据的操作，默认的STCS可能不太适合，可以考虑切换到LeveledCompactionStrategy（LCS）。LCS会更频繁地合并小SSTable，标记删除的数据会更快被清理，也能减少空间统计的偏差。
• 监控实际磁盘使用：别只依赖nodetool status的数值，直接监控节点磁盘挂载点的实际已用空间（比如用df -h或者监控工具），这个才是最准确的，避免被错误的统计值误导。

额外注意事项 #

• 删除表时一定要用DROP TABLE命令，而不是只删除数据，否则残留的SSTable文件会一直占着空间，就算数据被标记删除，文件也不会自动清理。
• 执行nodetool cleanup前，最好先备份一下关键数据，虽然这个操作是安全的，但以防万一。

内容的提问来源于stack exchange，提问作者Fernando