【发布时间】：2017-01-17 02:28:26
【问题描述】：
我想知道是否有办法让 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 我的集群最初位于 EC2 中，位于 18 个 m3.2xlarge 主机上。这些主机在压缩期间以非常高 (~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';
【问题讨论】：
标签： cassandra