cassandra Scylla -RF 2的两个节点没有相同的数据?

w9apscun  于 2023-11-18  发布在  Cassandra
关注(0)|答案(1)|浏览(152)

我有两个节点,我创建了一个这样的密钥空间:

DESCRIBE uzzstore

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

CREATE TABLE uzzstore.chunks (
    id blob PRIMARY KEY,
    size bigint
) WITH bloom_filter_fp_chance = 0.01
    AND caching = {'keys': 'ALL', 'rows_per_partition': 'ALL'}
    AND comment = ''
    AND compaction = {'class': 'SizeTieredCompactionStrategy'}
    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';

字符串
当前我只有节点1在接收查询(读/写),根据我对文档的理解,所有的写操作都应该被复制;因此,我假设两个节点的数据相同,我在第二个节点上添加了第二个节点,并多次刷新和修复这些节点,但是,我看到节点1大约有213,435,988行,而节点2只有206,916行,617行。

nodetool status
Datacenter: datacenter1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address        Load       Tokens       Owns    Host ID                               Rack
UN  192.168.1.51   17.5 GB    256          ?       15450683-e34b-475d-a393-ad25611398d8  rack1
UN  192.168.1.100  17.92 GB   256          ?       6cad2ba2-b22e-4947-a952-dc65c616a08f  rack1

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


这是一种预期的行为吗?我对副本的理解是否不正确?(注意,我给群集留了几次时间来配对)。

nbnkbykc

nbnkbykc1#

你是对的,如果你有一个两节点的集群和一个replication_factor 2的键空间,那么实际上每一段数据都将在两个节点上,如果你使用CL=ALL,你可以确定这在写操作完成时已经发生了-但是即使你使用CL=ONE,写操作仍然会 * 最终 * 发生在第二个节点上-通常非常快,但是在修复之后(你说你做了),你可以确保相同的数据出现在两个节点上,两个节点应该有完全相同的行数。
然而,您说“我看到节点1大约有213,435,988行,节点2只有206,916,617行。"。您对这些数字有多大把握?您是如何得到这些数字的?您真的扫描了表吗(你是如何将扫描限制在一个节点上的?),还是使用了某种“大小估计”功能?如果是后者,您应该注意,在Cassandra和Scylla上,这只是一个估计。(参见https://github.com/scylladb/scylladb/issues/9083),但在这两个例子中,是否进行了主要压缩nodetool compact)的问题会影响估计。您说您“刷新并修复”了表,但没有说您压缩了它。
无论如何,我想再次强调,即使压缩影响分区数量的估计,如果您使用SELECT * FROM table扫描整个表或使用SELECT COUNT(*) FROM table计数,则它不会对正确性或数据或您看到的准确行数产生任何影响。如果 * 提示切换 *,则 * 可能 * 需要修复未启用,并且您的群集在写入过程中出现连接问题-但既然您确实说您进行了修复,那么应该没有问题。

相关问题