cassandra - 取消 Cassandra 中正在进行的压缩作业

Question

我有 3 个节点集群。 3 个节点中有 2 个显示 100% CPU 使用率。

似乎我们并没有在更改一致性级别后调用repair 和cleanup(或者我们调用得太晚或者没有完成)

现在我们有 100k 多个压缩任务待处理。他们吃掉了 100% 的 CPU。

我试着跟随

nodetool stop -- COMPACTION
nodetool stop -- INDEX_BUILD
nodetool stop -- VALIDATION
nodetool stop -- CLEANUP
nodetool stop -- SCRUB

没有变化。也没有错误。

我收到的唯一信息是

No files to compact for user defined compaction 

有什么问题吗？我怎样才能取消正在进行的工作？

Answer 1

调用 nodetool stop COMPACTION 将停止当前压缩。如果您不希望它开始新的压缩，请使用 nodetool disableautocompaction。然后可以用nodetool compactionstats

验证

不过我确定这不是您的问题。有 100k 待处理的压缩，你将有太多的 sstables。您的节点无可救药地落后了。任何读取都将导致大量负载。此外，除非你有一个巨大的堆，否则仅仅试图从它们中读取可能会导致你在堆空间和 GC 问题上运行不足。 GC 可能是导致高负载的原因，如果您检查 CPU 时间，如果它花费在 IO 上，则可能来自读取或流式处理，如果它在 sys/usr 中，则可能是 GC。如果是 GC 问题，您可以进行堆转储并检查以验证是什么占用了所有空间。

你的节点落后 100k 可能永远无法自行恢复。您最好的选择可能是以下之一:

• Replace它甚至让它取代自己。
• 使用 nodetool disablebinary/disablethrift/disablegossip 从集群中删除它，然后使用 nodetool compact 强制压缩所有 sstables。根据版本和压缩策略，它可能不起作用，但您可以使用 jmx 将该节点的压缩策略本地更改为 STCS 以使其工作。如果这不能在提示的切换窗口中完成，那么不值得尝试再次使您的集群保持一致。此外，这仅在节点从集群中移除时负载下降的情况下才有效。
• 设置监控和警报，再也不会让它落后那么远。目标是 100 次以下的待处理压缩。