where 子句中的特定值导致 cassandra 中的 OperationTimedOut 错误

Question

我在 cqlsh 中有 5 个节点的 cassandra 集群中运行查询。它给了我 OperationTimedOut 错误。如果我对 where 子句参数进行轻微修改，它会给我空的结果。这是预期的。即使我更改参数的单个字符也没关系，但完全相同的参数值让我超时。为什么会这样？

查询：

select * from table where pid = '5f334fef-2629-484c-a081-c4a6f554c6ab'

这是表架构

CREATE TABLE dmp.interest_data (
    pid text,
    attribute text,
    country text,
    day_count int,
    first_seen timestamp,
    flag int,
    keys set<text>,
    last_seen timestamp,
    score int,
    usage_count int,
    PRIMARY KEY (pid, attribute)
) WITH CLUSTERING ORDER BY (attribute ASC)
    AND bloom_filter_fp_chance = 0.01
    AND caching = '{"keys":"ALL", "rows_per_partition":"NONE"}'
    AND comment = ''
    AND compaction = {'min_threshold': '4', 'class': 'org.apache.cassandra.db.compaction.LeveledCompactionStrategy', 'max_threshold': '32'}
    AND compression = {'chunk_length_kb': '256', '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 = 172800
    AND max_index_interval = 2048
    AND memtable_flush_period_in_ms = 0
    AND min_index_interval = 128
    AND read_repair_chance = 0.1
    AND speculative_retry = '99.0PERCENTILE';
CREATE INDEX interest_data_attribute_idx ON dmp.interest_data (attribute);
CREATE INDEX interest_data_country_idx ON dmp.interest_data (country);
CREATE INDEX interest_data_day_count_idx ON dmp.interest_data (day_count);
CREATE INDEX interest_data_first_seen_idx ON dmp.interest_data (first_seen);
CREATE INDEX interest_data_usage_count_idx ON dmp.interest_data (usage_count);

更新： where 子句中提到的 pid 的值应该存在于表中，因为它是通过没有给出任何错误的查询插入的。但是在查询它时会发生此超时。现在奇怪的事情发生了。我试过删除它，它被删除了！！！因为删除后我尝试选择相同的结果，但结果为空。因此，确实存在只是以某种损坏的形式导致超时。现在我需要知道这样的事情是怎么发生的

Answer 1

检查您的节点的状态，更改您查询的值会更改拥有该值的节点，因此您的一个节点很可能有问题并且超时的值归该节点所有。当您更改值时，新的值归另一个节点所有，因此不会超时。

Answer 2

Re：关于删除成功和损坏问题的更新。

当您使用一致性级别 1 进行查询和插入时，这肯定会发生（如评论中所述）。假设密钥空间中的复制因子高于 1（通常为 3）。 可能是该密钥中的一个或两个节点在插入期间关闭/损坏，有时（集群负载不足、维护问题等） - 复制没有完成它的工作，并且数据没有复制到复制的节点.

发生这种情况时，只有进行修复操作（或根本不进行操作）才能帮助解决问题。

结果是有 1-2 个服务器应该持有该行，但实际上并没有，这可能会导致各种奇怪的故障情况。

我对超时没有很好的解释，除非该行有很多列并且它只是没有“及时”完成

如果再次发生这种情况，请尝试使用 limit 子句（从 1 开始，如果可行，它可能是一个很长的查询并且自然会超时。