通过压缩和修复从 Cassandra db 中删除大量数据后，磁盘空间未更改

Posted 2023-03-17

【中文标题】通过压缩和修复从 Cassandra db 中删除大量数据后，磁盘空间未更改

【英文标题】：Disk space not changed after massive data removal from Cassandra db with compaction and repair

【发布时间】：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。

【参考方案1】：

假设您必须等待 gc_grace_seconds 才能删除的数据有资格最终删除其生成的墓碑。所以在适当的时候提前计划:)

这里有一个good link，用于了解 Cassandra 的内部工作以及删除与释放磁盘空间。也许可以考虑这个link 以及如何进行用户定义的压缩。

【讨论】：

注意，如果没有分级，在项目离开磁盘之前它可能比 GC 宽限长得多