Cassandra节点无空间执行垃圾回收，删除SSTables后修复是否可行？

方案可行性分析 #

你的方案完全可行。因为目标表的复制因子（RF）为10，集群所有节点都存储了该表的完整副本，删除问题节点上的该表SSTables后，通过nodetool repair --full可以从其他健康节点同步完整数据重建SSTables，最终能恢复该节点的磁盘占用至正常水平，同时保证数据完整性。

操作前的必要准备：刷新Memtable #

需要先执行flush操作，将Memtable中的数据持久化到SSTable：

nodetool flush <问题keyspace名称>.<问题表名称>

虽然你提到该表已不再写入，但flush能确保节点内存中残留的未持久化数据被落地，避免删除SSTables后丢失这部分数据。无需单独处理commitlog，flush完成后，该表对应的commitlog条目已失去作用，后续Cassandra会自动清理过期的commitlog内容。

对关键keyspace的影响规避 #

只要操作精准，不会对第二个关键keyspace造成任何影响：

• 删除SSTables时，务必定位到目标表的专属存储目录（默认路径为/var/lib/cassandra/data/<问题keyspace>/<问题表>-<随机UUID>），只删除该目录下的SSTable文件（如*.db、*.summary等），绝对不要触碰其他keyspace的文件。
• 执行repair时，指定具体的keyspace和表，而非全局repair：

  nodetool repair --full <问题keyspace名称>.<问题表名称>
  

  该命令只会同步目标表的数据，不会涉及第二个关键keyspace的任何操作。

额外操作建议 #

• 逐个处理问题节点：不要同时对多个问题节点执行删除SSTables和repair操作，避免短时间内集群同步压力过大，同时保证集群服务的连续性。
• 操作前验证数据完整性：在健康节点上随机查询目标表的部分数据，记录结果，待问题节点repair完成后，在该节点执行相同查询，确认数据一致。
• 检查磁盘空间：repair过程中会临时占用磁盘空间，确保问题节点的剩余磁盘空间足够容纳同步来的完整数据（可参考健康节点上该表的磁盘占用量）。

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