【发布时间】：2017-03-09 08:47:47
【问题描述】：
我们有一个 Cassandra 集群 (2.1.11)，它有 15 个节点，SSD 驱动器上的复制因子为 3。
其中一个表占用 12 TB。活动磁盘空间和总磁盘空间是相等的。我还在 Ops Center、JMX 报告和文件系统上的实际文件夹大小上验证了这个数字是相同的。
空间不足，因此我们删除了全部数据的 35%。 （每个条目有 104 个字节，因此我们删除了数十亿行）
然而，我们根本没有获得任何可用空间，尽管我们在删除条目时看到很多压缩正在进行。
从那以后，我们运行 nodetool repair / nodetool clean / restart process jvm，没有运气。
有人知道我还能做什么吗？
【问题讨论】：
-
请注意 GC 宽限，如果您的磁盘不足，您可以暂时降低它并触发压缩。
-
谢谢。我们已经运行了一周的夜间清理批处理。到现在还不到10天。我们可能会更改此值并重新启动过程。将更新进展情况。
-
我们已将 gc_grace_periods 设置为 3 天，并开始修复过程。我们还没有重新开始这个过程。我当然看到了下降趋势，但它非常缓慢。过去 3 天，我们只看到释放了 30GB 空间。我们应该更好地重新启动所有盒子，还是等到整个修复过程完成？我们的维修过程通常需要 7 - 10 天。
-
它的压缩不能修复清理磁盘空间。如果您使用的是 stcs，则没有保证所有已删除的数据将被及时清理。你可能需要考虑水平。
-
谢谢。我们在那个特定的索引表上使用 LeveledCompactionStrategy。我们将停止修复过程并改为运行 nodetool compact。
标签： cassandra diskspace repair nodetool