【问题标题】:Disk space not decreasing after gc_grace_seconds (10 days) elapsedgc_grace_seconds(10 天)过去后磁盘空间未减少
【发布时间】:2019-06-26 03:20:17
【问题描述】:

我从我的表中删除了很多数据(100 亿行)(制作了一个小应用程序,在令牌范围内从 LONG.MIN_VALUE 查询到 LONG.MAX_VALUE 并删除了一些数据)。

从那时起 20 天后磁盘空间没有减少(我也在总共 6 个节点中的 1 个节点上运行 nodetool repair),但密钥(估计)数量相应减少。

未来空间会以自然方式减少,还是我需要运行 cassandra 的一些实用程序来回收空间?

【问题讨论】:

    标签: cassandra


    【解决方案1】:

    一般来说,是的,空间会相应减少(一旦压缩运行)。根据为该表选择的压缩策略,可能需要一些时间。例如,大小分层压缩策略默认情况下要求 4 个 sstable 在压缩之前具有相同的大小。如果您有非常大的 SSTABLES,那么它们可能会在相当长的一段时间内无法压缩,或者如果没有 4 个相同大小的 SSTABLE,则可能会无限期压缩。手动压缩可以解决这种情况,但它会将所有内容放在一个 sstable 中,这也不推荐。如果手动压缩的结果 sstable 非常小,那么它不会伤害你。如果它最终被压缩成一个“大”的 SSTABLE,那么你已经为“以后”牺牲了“现在”(同样,因为你现在只有一个大的 sstable,它可能需要很长时间才能参与压缩) .您可以在手动压缩后拆分 sstable 以弥补您创建的情况,但您必须让您的节点离线才能执行此操作。无论如何,简短的回答是随着时间的推移表应该相应地缩小 - 何时取决于选择的压缩策略。

    【讨论】:

    • 瓦特尼奇 谢谢。我决定坐下来等待,让“自然”完成它的工作:)。压缩是默认的,SizeTieredCompactionStrategy。
    【解决方案2】:

    尝试运行“nodetool 垃圾收集”,因为这将触发压缩并删除已删除的数据。您可以通过“nodetool compacationstats”验证运行状态

    【讨论】:

      猜你喜欢
      • 2021-11-17
      • 2022-01-09
      • 2019-11-14
      • 1970-01-01
      • 2016-09-14
      • 1970-01-01
      • 1970-01-01
      • 2019-07-14
      • 2018-10-01
      相关资源
      最近更新 更多