Cassandra 中副本之间的计数器值不一致

发布于 2024-11-28 16:43:42 字数 1056 浏览 1 评论 0原文

我有一个 3 台机器的 Cassandra 集群，使用机架不知道的放置策略，复制因子为 2。

列族定义如下：

create column family UserGeneralStats  with  comparator = UTF8Type  and default_validation_class = CounterColumnType;

不幸的是，经过几天的生产使用，我得到了一些不一致的计数器值：

副本 1 上的查询：

[default@StatsKeyspace] list UserGeneralStats['5261666978': '5261666978'];  
Using default limit of 100
-------------------
RowKey: 5261666978
=> (counter=bandwidth, value=96545030198)
=> (counter=downloads, value=1013)
=> (counter=previews, value=10304)

对副本 2 的查询：

[default@StatsKeyspace] list UserGeneralStats['5261666978': '5261666978'];
Using default limit of 100
-------------------
RowKey: 5261666978
=> (counter=bandwidth, value=9140386229)
=> (counter=downloads, value=339)
=> (counter=previews, value=1321)

由于标准读取修复机制似乎无法修复我试图强制执行的值使用nodetool修复进行反熵修复。它对计数器值没有任何影响。

数据检查显示计数器的较低值是正确的，因此我怀疑 Cassandra（或我用作 API 从 Java 调用 Cassandra 的 Hector）重试了一些增量。

有什么想法可以修复数据并可能防止这种情况再次发生吗？

原文

I've got a 3 machine Cassandra cluster using rack unaware placements strategy with a replication factor of 2.

The column family is defined as follows:

create column family UserGeneralStats  with  comparator = UTF8Type  and default_validation_class = CounterColumnType;

Unfortunately after a few days of production use I got some inconsistent values for the counters:

Query on replica 1:

[default@StatsKeyspace] list UserGeneralStats['5261666978': '5261666978'];  
Using default limit of 100
-------------------
RowKey: 5261666978
=> (counter=bandwidth, value=96545030198)
=> (counter=downloads, value=1013)
=> (counter=previews, value=10304)

Query on replica 2:

[default@StatsKeyspace] list UserGeneralStats['5261666978': '5261666978'];
Using default limit of 100
-------------------
RowKey: 5261666978
=> (counter=bandwidth, value=9140386229)
=> (counter=downloads, value=339)
=> (counter=previews, value=1321)

As the standard read repair mechanism doesn't seem to repair the values I tried to force an
anti-entropy repair using nodetool repair. It did't have any effect on the counter values.

Data inspection showed that the lower values for the counters are the correct ones so I suspect that either Cassandra (or Hector which I used as API to call Cassandra from Java) retried some increments.

Any ideas how to repair the data and possibly prevent the sittuation from happening again?

分享到QQ

分享到微博