我正在使用一个有10个节点的Cassandra集群。不幸的是，在这些节点上，我们使用了2个单独的键空间：第一个中有2个表，第二个中有1个表。
我们的问题似乎来自第一个键空间中的一个表。我们的复制因子为10，所以我假设每个节点上都有整个表的副本，但是这4个节点的磁盘使用率明显高于其他6个节点。大约30%/40%%。
我尝试在一个有问题的节点上运行“nodetool -h localhost garbagecollect”，但不幸的是，由于以下原因，该过程甚至没有启动：“* 没有足够的空间用于压缩，估计sstables = 1，预期写入大小= 61055287773*"。
我的猜测是，在某个时候，由于上述问题，无法启动garbagecollect过程，并且从那时起，根本没有删除过期的行。前几个月的存储变化图似乎表明了类似的情况。此外，删除历史没有关于此表上完成的任何操作的数据。
因此，作为一种潜在的修复方法，我正在考虑在4个有问题的节点上删除该表的SSTables，考虑到该表不再插入。然后在每个节点上运行：“nodetool -h localhost repair --full”，以便它们从剩余的6个节点复制该表的数据（在重新创建SSTables的过程中？）。这是一个合理的，或者完全可以实现的选择吗？我应该在删除SSTables之前提前刷新这个表的commitlog和Memtable吗？
不幸的是，正如前面提到的，这些节点上的第二个keyspace对我们来说非常重要，因为它甚至有一个更小的复制因子5，所以副本在所有节点上都不可用。我担心删除不再使用的表的SSTables并修复它可能会导致其他keyspace上的重要表出现问题。