ScyllaDB:在Scylla集群中的不同节点上运行CQL查询会得到不同的结果
我使用的是Scylla版本4.6.3。我在一个DC中有一个由3个节点组成的集群。我按照https://docs.scylladb.com/operating-scylla/procedures/cluster-management/add-dc-to-existing-dc/中给出的指令在一个新的DC中添加了3个新的节点。在新DC中的节点启动后，我检查nodetool状态并确保所有节点都已启动和运行。现在，由于所有节点都是同一个集群的一部分，所以我假设无论在哪个节点上运行cql查询，查询结果都应该是相同的，不是吗？但是，当查询在不同的节点上运行时，我发现数据是不同的。实际上，当查询在同一DC的不同节点上运行时，查询结果也是不同的！观察到以下差异(但这不是一个完整的列表)：
- On N1，一些主键没有记录，但是在N2上，对于同一个主键有一些记录。在N1上，记录的计数显示出与N2不同的值。在相同的DC以及交叉DC.
中的不同节点之间存在着这种差异。
在添加新的DC时，作为文档中描述的步骤的一部分，我将其修改为在两个DC中使用复制因子为2的：。
ALTER KEYSPACE ks WITH replication = { 'class' : 'NetworkTopologyStrategy', 'existing-dc' : 2, 'new-dc' : 2};为什么会有这种区别呢？我遗漏了什么？这是一个示例键空间和表定义：
CREATE TABLE ks.cf (
hourofyear int,
operationtime bigint,
action text,
entityid text,
entitytype text,
operatorid text,
PRIMARY KEY (hourofyear, operationtime)
) WITH CLUSTERING ORDER BY (operationtime DESC)
AND bloom_filter_fp_chance = 0.01
AND caching = {'keys': 'ALL', 'rows_per_partition': 'ALL'}
AND comment = ''
AND compaction = {'class': 'LeveledCompactionStrategy'}
AND compression = {'sstable_compression': 'org.apache.cassandra.io.compress.LZ4Compressor'}
AND crc_check_chance = 1.0
AND dclocal_read_repair_chance = 0.0
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 = '99.0PERCENTILE';
CREATE INDEX auditid ON ks.cf (entityid);
CREATE INDEX agentid ON ks.cf (operatorid);
CREATE INDEX auditaction ON ks.cf (action);示例查询：
select count(*) from ks.cf where hourofyear = 4444;这个查询在不同的运行中给出了不同的结果(甚至在同一分钟内)。有时，它在所有的ndoes上显示相同的结果。--数据不再被写入这个键空间了。，为什么我在多次运行时看到了这种差异？
cqlsh> select count(*) from ks.cf where hourofyear = 4446;
count
-------
1072
cqlsh> select count(*) from ks.cf where hourofyear = 4446;
count
-------
1545两场比赛相距只有几秒钟。为什么会有区别？有人能帮我把灯照一下吗？
回答 1
Stack Overflow用户
发布于 2022-07-11 10:40:41
您没有提到上次在这个集群上运行nodetool repair (或者使用Scylla运行修复)是什么时候。
ScyllaDB (以及Cassandra)使用最终的一致性，这意味着当该请求的一致性级别(CL)达到时，您的写入请求将得到满足。
如果您在写操作时使用了CL=ONE，那么应用程序只需要一个副本就可以认为这是成功的。对第二个副本的复制将同步进行(也可能由于各种原因而失败)。
下面是反熵机制，您可以在这里更多地了解它们：https://docs.scylladb.com/architecture/anti-entropy/。
必须确保集群在表的gc_grace_seconds值之前完成了集群范围的修复(默认为10天)
您还应该在添加第二个DC之前完全修复您的集群，或者至少在添加第二个DC之后完成它。这也写在我们的文档中。
除此之外，您正在运行一个CQL查询，除非您更改了CQL查询CL，否则它将使用默认的CL=ONE。这意味着集群中的每个副本(来自两个DC中的任何一个)都可以响应您的读取请求，而且如上所述，当前的数据很可能不一致。
了解更多关于体系结构的->环体系结构/ CL：https://docs.scylladb.com/architecture/console-CL-full-demo/ https://docs.scylladb.com/architecture/ringarchitecture/
我强烈建议你访问锡拉大学，了解更多我在这里写的东西，以及更多：https://university.scylladb.com/courses/scylla-essentials-overview/lessons/architecture/
https://stackoverflow.com/questions/72934006
复制相似问题
腾讯云开发者
