Question

我想知道是否有一种方法可以让Cassandra节点在完成流式传输和压缩后加入环。我遇到的问题是，当我向我的集群添加一个节点时，它会从其他节点流式传输数据然后加入环，此时它会开始大量的压缩，并且压缩需要很长时间才能完成（大于一天），在此期间该节点上的CPU利用率接近100％，并且布隆过滤器误报率也非常高，这恰好与我的用例相关。这会导致整个群集的读取延迟增加，新加入的节点特别是读取的典型延迟时间的10倍。

我读过这篇文章http://www.datastax.com/dev/blog/bootstrapping-performance-improvements-for-leveled-compaction，其中有一个关于添加节点时可能改善读取延迟的方法的片段。

“运行者通常通过在启动新节点时传递-Dcassandra.join_ring = false并等待引导程序与后续压缩一起完成，然后使用nodetool join手动将节点放入环中来避免此问题”

关于join_ring选项的文档非常有限，但在试验之后，似乎直到我为新主机运行nodetool join之后才能启动流数据和后来的压缩，所以我想要知道如何实现这一目标。

现在我的用例只是重复删除由kafka消费者应用程序处理的记录。 cassandra中的表非常简单，只是一个主键，查询只是插入几天ttl的新键并检查键的存在。群集需要在峰值流量时执行50k读取和每秒50k写入。

我正在运行cassandra 3.7我的群集最初是在18 m3.2xlarge主机上的EC2中。这些主机在压缩期间以非常高的（~90％）CPU利用率运行，这是尝试向集群添加新节点的动力，我已经切换到c3.4xlarge以提供更多CPU而无需实际添加主机，但是知道我应该添加新主机的CPU阈值是有帮助的，因为等到90％显然不安全，并且添加新主机会加剧新添加主机上的CPU问题。

CREATE TABLE dedupe_hashes (
   app int,
   hash_value blob,
   PRIMARY KEY ((app, hash_value))
) WITH bloom_filter_fp_chance = 0.01
       AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
    AND comment = ''
    AND compaction = {'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 'max_threshold': '32', 'min_threshold': '4'}
    AND compression = {'chunk_length_in_kb': '64', 'class': 'org.apache.cassandra.io.compress.LZ4Compressor'}
    AND crc_check_chance = 1.0
    AND dclocal_read_repair_chance = 0.1
    AND default_time_to_live = 0
    AND gc_grace_seconds = 864000
    AND max_index_interval = 2048
    AND memtable_flush_period_in_ms = 0
    AND min_index_interval = 128
    AND read_repair_chance = 0.0
    AND speculative_retry = '90PERCENTILE';

Answer 1

要检查的一件事可能有助于避免由于压缩导致的100％CPU，这是“compaction_throughput_mb_per_sec”的设置。默认情况下，它应该是16MB，但检查是否已将此禁用（设置为0）。

nodetool getcompactionthroughput

您也可以动态设置值

nodetool setcompactionthroughput 16

（在cassandra.yaml中设置以在重启后保持）。

新的cassandra节点应该在加入ring

1 个答案: