Cassandra有多行具有相同的分区和集群键

Question

有一个包含 5 个节点的 Cassandra 集群。最近完成了从 2.2.7 到 3.9 版本的逐个更新。更新是根据 Datastax 描述的过程完成的:upgrade instruction .一切都很顺利。整个过程耗时约 1 小时。但是，几个小时后，我发现了以下问题:对于更新周期，一些数据是不一致的，即对于特定的分区键和集群键，应该只返回一行。但有时会返回一个，有时会返回两个 - 对于同一个查询。

该表具有以下 PRIMARY KEY: ((id, year), date time)。所以，查询

SELECT * FROM table_name 
  WHERE id=1 and year=2017 and datetime='2017-01-01T01:01:01:000Z';

有时返回一行，有时返回两行。

此外，这些行是不同的，只有主键的字段是相同的。

结果示例:

id | year | datetime                | field1 | field2 | field3 | field4
---+------+-------------------------+--------+--------+--------+--------
1  | 2017 | 2017-01-01 01:01:01.000 |   null |   null |      5 |      6
1  | 2017 | 2017-01-01 01:01:01.000 |      3 |      4 |   null |   null

因此，如您所见，第一行有字段:field3 和 field4 不为空，而第二行有 field1 和 field2 不为空。相同的模式适用于其余损坏的数据。

此外，一旦我尝试删除这些行，只有第一行消失而第二行保留。我确定字段“日期时间”是相同的，这不是毫秒问题，因为 blobAsBigint(timestampAsBlob(datetime)) 为两行返回相同的值。

做了什么:

nodetool upgradesstables my_keyspace(在每个节点上一个接一个)

nodetool repair my_keyspace(在每个节点上一一修复)

upgradesstable 是必需的，因为最初修复返回“验证失败”错误: https://support.datastax.com/hc/en-us/articles/205256895--Validation-failed-when-running-a-nodetool-repair

CREATE TABLE my_keyspace.my_table (
    id bigint,
    year int,
    datetime timestamp,
    field1 int,
    field2 int,
    field3 set<bigint>,
    field4 boolean,
    field5 map<int, text>,
    field6 timestamp,
    field7 decimal,
    field8 decimal,
    PRIMARY KEY ((id, year), datetime)
) WITH CLUSTERING ORDER BY (datetime 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';

Answer 1

升级到 3.11 并执行 nodetool scrub。在 3.0.11 和 3.11 中修复了迁移中的错误

参见:https://issues.apache.org/jira/browse/CASSANDRA-13125详情