获取 Cassandra tombstone_warn_threshold 错误答案

【问题标题】：Getting Cassandra tombstone_warn_threshold error获取 Cassandra tombstone_warn_threshold 错误
【发布时间】：2017-03-03 15:14:41
【问题描述】：

我们在生产中设置了 Cassandra。有几个表，其中包含大约 20M 条记录。为了减少记录的数量，我们删除了不需要的记录，并且还设置了 ttl 以在一段时间后删除数据。我们现在已将宽限期设置为 1 天。我们还在每个 Cassandra 节点上运行了 nodetool 修复（一次一个）。我们在集群中总共有 5 个节点，replication_factor 为 3。Cassandra 版本是 2.1.14

在 Cassandra 日志中，我经常看到以下错误：

WARN  [SharedPool-Worker-33] 2017-02-23 06:09:02,617 SliceQueryFilter.java:320 - Read 207 live and 3059 tombstone cells in event for key: 101:10001Njh:22017 (see tombstone_warn_threshold). 5000 columns were requested, slices=[-]

我运行了命令 nodetool cfhistograms myekyspace event；以下是相同的输出

我无法完全分析上述输出，但我知道 sstable 计数过高。

关于我们可以做些什么来解决这个问题或优化我们的 Cassandra 的任何想法。

java 堆大小设置为 8 GB，我们正在使用 CMS 垃圾回收。

nodetool cfstats mykeyspace.event 的输出

表结构

@chris-lohfink  - Updated the question with the cfstats details and 
CREATE TABLE vcs.events (
    v_id text,
    c_id text,
    e_month int,
    sid text,
    e_id timeuuid,
    cr_p_id text,
    e_bucket text,
    e_media map<text, text>,
    e_meta map<text, text>,
    e_met map<text, double>,
    tag set<text>,
    etime timestamp,
    etype text,
    isfin boolean,
    r_mode text,
    state text,
    PRIMARY KEY ((v_id, c_id, e_month), sid, e_id)
) WITH CLUSTERING ORDER BY (sid ASC, e_id ASC)
    AND 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'}
    AND compression = {'sstable_compression': 'org.apache.cassandra.io.compress.LZ4Compressor'}
    AND dclocal_read_repair_chance = 0.1
    AND default_time_to_live = 0
    AND gc_grace_seconds = 86400
    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 = '99.0PERCENTILE';
CREATE INDEX events_id_idx ON mykeyspace.event (e_id);
CREATE INDEX events_type_idx ON mykeyspace.event (etype);
CREATE INDEX events_finalized_idx ON mykeyspace.event (isfin);
CREATE INDEX idx_state ON mykeyspace.event (state);

【问题讨论】：

你试过nodetool compact
nodetool repair 也会进行压缩。我在 cassandra 日志中看到了压缩日志。
@chris-lohfink 你能帮忙吗？
docs.datastax.com/en/archived/cassandra/2.0/cassandra/tools/…... 试试compaction，compaction后墓碑应该没有了
谨慎使用手动压缩。它将创建一个可能永远不会再次压缩的大型 sstable。

标签： cassandra cassandra-2.0 cassandra-2.1

【解决方案1】：

当您在 Cassandra 中删除数据时，数据不会立即删除，而是 Cassandra 会创建墓碑，指示行/列已删除。墓碑存储到 gc_grace_seconds。

在您的情况下，您每天删除 30 万条记录，这表明创建了更多墓碑并影响了您的性能。您应该处理您的数据模型以避免此错误。在http://www.slideshare.net/planetcassandra/8-axel-liljencrantz-23204252 中查看关于删除和 TTL 的幻灯片 34 到 42

还可以从以下 Cassandra 文档中查看数据模型对墓碑的影响： http://www.datastax.com/dev/blog/cassandra-anti-patterns-queues-and-queue-like-datasets

【讨论】：