Cassandra 手动主要压缩更改次要压缩的频率答案

【问题标题】：Cassandra manual major compaction changes frequency of minor compactionsCassandra 手动主要压缩更改次要压缩的频率
【发布时间】：2014-12-25 18:13:53
【问题描述】：

我对 Datastax 页面中关于调整 cassandra 压缩的以下几行有点不清楚。他们特别提到：

“管理员还可以通过nodetool compact启动一次major compaction，它将所有SSTables合并为一个。虽然major compaction可以释放累积的SSTables使用的磁盘空间，但在运行时它会暂时使磁盘空间使用量翻倍，并且是I/O和CPU密集型的. 另外，一旦你运行了一个major compaction，自动的minor compactions 不再频繁触发，迫使你在例行的基础上手动运行major compactions。因此，虽然在major compaction 之后立即读取性能会很好，但它会持续降低直到下一次主要压缩是手动调用的。因此，DataStax 不推荐主要压缩。 (http://www.datastax.com/docs/1.0/operations/tuning)

读完这篇文章后，我想更好地理解的两个问题是：

为什么手动触发的主要压缩会更改次要压缩间隔/频率？我不太确定我是否遵循这背后的根本原因。
如果我确实需要使用 nodetool 手动运行主要压缩，是否有可能？如果可以，我如何恢复以确保次要压缩间隔不会因此受到影响并重置为默认行为。

谢谢。

【问题讨论】：

你为什么要看这么老的文档？谷歌热门？自 1.0 以来，压缩发生了许多变化和改进，文档现在说了一些不同的东西：website-staging.dev.datastax.com/documentation/cassandra/2.1/…
这确实是谷歌点击@catpaws。直到你指出来，我才意识到这是一个如此古老的文件。但是，我无法打开您上面的链接，因为它说我需要身份验证。您还有其他参考资料可以指点我吗？
抱歉，罗希特。这就是我要指出的：datastax.com/documentation/cassandra/2.1/cassandra/dml/…
没问题。感谢您的新链接。它看起来确实有很大不同，所以这不是我需要担心的事情。

标签： cassandra datastax nodetool

【解决方案1】：

回答你的第二个问题：

“是否有可能？如果可以，我该如何恢复以确保次要压缩间隔不会受到影响”

[CASSANDRA_HOME]/bin/nodetool enableautocompaction

http://datastax.com/documentation/cassandra/2.0/cassandra/tools/toolsNodetool_r.html

【讨论】：

我认为您是说无法恢复。相反，您是在说，“不要执行主要压缩，只需使用自动压缩（这将是次要的。”

【解决方案2】：

当major compaction运行时，它会将所有的SSTables合并到一个SSTable中。在大多数情况下，新创建的 SSTable 将明显大于将从 Memtable 中刷新的下一个 SSTable（使用 memtable_total_space_in_mb 定义）。如果您使用大小分层压缩，cassandra 将等待 4 个（再次默认）相同大小的 SSTable，然后再触发下一次次要压缩。这会延迟下一次自动次要压缩，因为主要压缩创建的 Cassandra SStable 不会与其他 SSTable (memtable_total_space_in_mb) 对齐。所以 Cassandra 不一定会停止自动小压缩，但现在改变了频率。

“是否有可能，如果可以，我该如何恢复以确保次要压缩间隔不会因此受到影响并重置为默认行为。” - 为此，您将不得不打破由于主要压实而创建的大型稳定。为此，您可以使用名为“sstablesplit”的实用程序。

https://docs.datastax.com/en/cassandra/2.1/cassandra/tools/toolsSSTableSplit.html

【讨论】：