cassandra中的主要压缩答案

【问题标题】：Major compaction in cassandracassandra中的主要压缩
【发布时间】：2011-10-04 16:32:33
【问题描述】：

我有一个 4 节点 Brisk 集群，在 Cassandra DC 中有 2 个 Cassandra 节点，在 Brisk DC 中有 2 个 Brisk 节点。我使用压力工具对这个设置进行了压力测试，该工具与 cassandra 一起提供了 1000 万次写入

在执行中

$ ./nodetool -h x.x.x.x compactionstats

pending tasks: 17
          compaction type        keyspace   column family bytes compacted     bytes total  progress
                    Major       Keyspace1       Standard1        45172473        60278166    74.94%

AFAIK 主要压缩是从节点工具手动触发的。但是我可以看到它已经被自动触发了。这是理想的行为吗？如果是这样，这可能发生的所有情况是什么？

问候，泰米尔语

【问题讨论】：

标签： cassandra

【解决方案1】：

来自文档：

当至少 N 个 SStables 被刷新时触发压缩到磁盘，其中 N 是可调的，默认为 4。

“次要”压缩合并相似大小的 sstable； “主要”压缩合并给定 ColumnFamily 中的所有 sstable。

再次来自文档：

通过 nodeprobe，或自动触发主要压缩：

Nodeprobe 向目标的所有邻居发送 TreeRequest 消息 node：当一个节点收到一个TreeRequest，它会执行一个readonly 压缩以立即验证列族。

自动压缩还将验证列族和广播 TreeResponses，但由于 TreeRequest 消息未发送到相邻节点，仅当两个节点发生时才会发生修复在 TREE_STORE_TIMEOUT 1 内执行自动压缩另一个。

您可以找到更多信息 here 和 here

【讨论】：