卡桑德拉复制节点在尝试从密钥空间读取时失败

Question

我的Cassandra (3.0.2)复制集中有3个节点。我的一致性水平是“一”。开始时，我所有的键空间的复制因子都等于1。我通过改变表来改变它，并在所有节点上运行“nodetool repair”。现在，当我试图选择一些数据(不是在每个键空间上)时，我得到类似这样的结果(select * from keyspace.table):

回溯（最近调用最后）：文件“/usr/bin/cqlsh.py”，第 1258 行，perform_simple_statement 结果 = future.result（） 文件“cassandra/cluster.py”，第 3781 行，在 cassandra.cluster.ResponseFuture.result （cassandra/cluster.c：73073） 引发self._final_exception 读取失败：来自服务器的错误：代码=1300 [副本无法执行读取] 消息=“操作失败 - 收到 0 个响应和 1 个失败” 信息={“失败”：1，“received_responses”： 0， 'required_responses'： 1， '一致性'： 'ONE'}

在“/var/log/cassandra/system.log”中，我得到：

另外，我得到：

DEBUG[SharedPool-Worker-1] 2017-04-07 13:20:30,002ReadCallback.java:126-超时；收到0/1的回复

我检查了端口9042和7000上的节点之间是否存在连接。我更改了“/etc/cassandra/cassandra.yml”中的选项，如“read_request_timeout_in_ms”、“range_requeste_timeoout_in_ns”、“write_request _timeout_in_s”或“truncate_request_temeout_in _ms”。我更改了文件“~/.cassandra/cqlshrc”和选项“client_timeout=3600”。另外，当我这样做时，例如“从keyspace.table中选择*，其中column1='value'，column2=value”，我得到：

ReadTimeout:来自服务器的错误:code = 1200[协调器节点等待副本节点响应超时] message= "操作超时-仅收到0个响应。"info={'received_responses': 0，' required_responses': 1，' consistency': 'ONE'}

有什么想法吗？

Answer 1

固定！我将卡桑德拉版本从3.0.2更改为3.0.9，问题解决了。

Answer 2

Markošvaljek，是的，我将复制因子从1更改为3（因为我的复制中有3个节点）。你是对的；你改变了密钥空间的复制因子，这就是我所做的。这里有我的密钥空间的描述，通常我会在这里遇到一些错误（当然，在其他密钥空间中也会发生这种情况）：

soi@cqlsh> desc keyspace engine;

CREATE KEYSPACE engine WITH replication = {'class': 'SimpleStrategy', 'replication_factor': '3'}  AND durable_writes = true;

CREATE TABLE engine.messages (
    persistence_id text,
    partition_nr bigint,
    sequence_nr bigint,
    timestamp timeuuid,
    timebucket text,
    message blob,
    tag1 text,
    tag2 text,
    tag3 text,
    used boolean static,
    PRIMARY KEY ((persistence_id, partition_nr), sequence_nr, timestamp, timebucket)
) WITH CLUSTERING ORDER BY (sequence_nr ASC, timestamp ASC, timebucket ASC)
    AND bloom_filter_fp_chance = 0.01
    AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
    AND comment = ''
    AND compaction = {'bucket_high': '1.5', 'bucket_low': '0.5', 'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 'enabled': 'true', 'max_threshold': '32', 'min_sstable_size': '50', 'min_threshold': '4', 'tombstone_compaction_interval': '86400', 'tombstone_threshold': '0.2', 'unchecked_tombstone_compaction': 'false'}
    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 = '99PERCENTILE';

CREATE MATERIALIZED VIEW engine.eventsbytag1 AS
    SELECT tag1, timebucket, timestamp, persistence_id, partition_nr, sequence_nr, message
    FROM engine.messages
    WHERE persistence_id IS NOT NULL AND partition_nr IS NOT NULL AND sequence_nr IS NOT NULL AND tag1 IS NOT NULL AND timestamp IS NOT NULL AND timebucket IS NOT NULL
    PRIMARY KEY ((tag1, timebucket), timestamp, persistence_id, partition_nr, sequence_nr)
    WITH CLUSTERING ORDER BY (timestamp ASC, persistence_id ASC, partition_nr ASC, sequence_nr 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', '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 = '99PERCENTILE';

CREATE TABLE engine.config (
    property text PRIMARY KEY,
    value text
) 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 = '99PERCENTILE';

CREATE TABLE engine.metadata (
    persistence_id text PRIMARY KEY,
    deleted_to bigint,
    properties map<text, text>
) 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 = '99PERCENTILE';

通常我得到代码错误号1200或1300，如您在第一篇文章中看到的那样。这里有我的“节点工具状态”：

ubuntu@cassandra-db1:~$ nodetool status
Datacenter: datacenter1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address       Load       Tokens       Owns    Host ID                               Rack
UN  192.168.1.13  3.94 MB    256          ?       8ebcc3fe-9869-44c5-b7a5-e4f0f5a0beb1  rack1
UN  192.168.1.14  4.26 MB    256          ?       977831cb-98fe-4170-ab15-2b4447559003  rack1
UN  192.168.1.15  4.94 MB    256          ?       7515a967-cbdc-4d89-989b-c0a2f124173f  rack1

Note: Non-system keyspaces don't have the same replication settings, effective ownership information is meaningless

我不认为其他进程可以操纵磁盘上的数据。我要补充的是，我有类似的复制，我有更多的数据，我没有这样的问题。

Answer 3

这或多或少是一个评论，但既然有这么多话要说，它就不适合评论。

如果能说出您更改了值的复制因子，那将是非常好的。我只是假设它是3，因为它相当标准。然后，由于您只有3人的集群，有时会将RF设置为2。您还提到您更新了表上的复制因子。据我所知，复制因子是在密钥空间级别设置的。

如果您发布了发生错误的密钥空间的描述，这将非常有帮助。

考虑到select*from某物在集群中可能会变得非常密集，特别是如果您有大量数据的话。如果你在cqlsh中做这个查询，你可能会得到10000，然后你只提到cqlsh，没有应用程序代码，所以我只是注意到这一点。

请您提供＜code＞nodetool状态＜/code＞，以确保您实际上没有在某些节点关闭的情况下运行查询。因为第一个错误看起来像这样。

到您发布堆栈跟踪的第二个错误时，它看起来就像您在磁盘上缺少一些稳定？是否有可能其他过程以某种方式操纵了稳定器？

你还改变了cassandra.yaml的很多属性，基本上你将预期响应时间减少了近50%，我想难怪节点没有时间响应……计算整个表通常需要3.6秒以上。

为什么这些值被改变的原因根本就不存在。