如何在 Cassandra 中强制清理/压缩答案

【问题标题】：How to force cleanup/compaction in Cassandra如何在 Cassandra 中强制清理/压缩
【发布时间】：2017-10-02 18:59:25
【问题描述】：

我使用 Cassandra 2.1.8 来管理各种资产，主要是图像。使用 Leveled Compaction 在主 CF 的 3 个节点上使用 RF=3 设置集群。我从集群中删除了大部分数据（使用包含大量删除的 CQL 脚本），但尚未回收空间。此外，一个节点在 SSTables 上遇到了损坏，我选择清除其数据并运行修复以重新创建它。现在，修复的节点现在在 100 个 SSTables 中使用 250GB，而另外两个在 300 个 SSTables 中使用 750GB。 “nodetool cfstats”在一个节点上显示 4.5M 键，在其他两个节点上显示 17M。

有没有办法强制清理这 2 个节点？运行“nodetool compact”似乎对 2 个节点没有太大影响 - 而且完成得相当快。

【问题讨论】：

标签： cassandra

【解决方案1】：

空间没有被回收的原因是因为 Cassandra 中的删除不是“即时的”——至少从存储的角度来看是这样。直到GC_GRACE 过期并且压缩运行，数据才被有效地删除。

现在每个人的第一反应是去设置GC_GRACE=0，以便数据更快地消失。那不是你想做的。原因如下：https://lostechies.com/ryansvihla/2014/10/20/domain-modeling-around-deletes-or-using-cassandra-as-a-queue-even-when-you-know-better/

您的脚本执行了大量删除操作 - 是否执行了整个分区的删除操作？还是列删除？请注意，您在压缩期间可能会遇到一些开销，具体取决于您执行了多少删除操作以及您执行删除操作的方式。

【讨论】：

gc_grace_seconds 是 86400（1 天）对于这个 CF，我大约一周前运行了删除。令我困惑的是，修复后的节点只能获取活动的内容，而其他两个似乎可以保持更长的数据保存时间。删除是针对整个分区运行的，不限于列。
有趣的是，当您在每个节点上运行 nodetool cfstats 时，它告诉您“最大”和“最小”压缩分区大小是什么？我想知道您是否有大分区，看起来好像旧数据在那里。否则，您可能留下了可以通过运行“nodetool clearsnapshot”docs.datastax.com/en/cassandra/2.1/cassandra/tools/… 来修复的快照
没有快照。以下是来自 cfstats 的相关信息，在 2 个节点之间（一个包含我希望拥有的数据，另一个似乎承载太多）：
没有快照。如果用最小/最大表示使用的空间与总空间，它们在每个节点中都是相同的（2 个节点在 ~700GB，一个节点在 ~150GB）。 cfstats 还显示了估计的密钥差异（当前为 2.7M 与 16M）。感觉有些墓碑没有进入我的 3 个节点中的 2 个。

【解决方案2】：

我也遇到过类似的墓碑没有被删除的问题。解决方案是在表上设置 unchecked_tombstone_compaction 属性。

如果我理解正确，这将允许删除，即使表没有完全修复

ALTER TABLE myTable WITH COMPACTION = { 'class': 'DateTieredCompactionStrategy','unchecked_tombstone_compaction': 'true' };

【讨论】：