cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Yeschenko (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-8752) invalid counter shard detected in Version 2.1.2
Date Sat, 07 Feb 2015 02:45:34 GMT


Aleksey Yeschenko commented on CASSANDRA-8752:

bq. Switching to another version is not an easy decision for my project. So we hope to fix
the issuse in our 2.1.2 code.

You *will* have to upgrade to 2.1.3 once it's out. Unfortunately 2.1.2 is simply unstable
enough for production use. There is no decision to make, because there are no options.

So, as I said, please try cassandra-2.1 branch recent, or wait till next week, upgrade to
2.1.3 when it's out, and tell me if you can still replicate. Given that you see the issue
during compaction time, this is most likely fixed by one of the 2.1.3 sstable tickets.

As for your steps, 2) and 3) are impossible, there is no such thing as reading the data file
asynchronously. Cassandra will not start serving requests until it replays the commitlog and
loads the sstables. 4) and 5) are what's happening, except it's not because 'the data file
is not loaded', which is not a thing.

> invalid counter shard detected in Version 2.1.2
> -----------------------------------------------
>                 Key: CASSANDRA-8752
>                 URL:
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Core
>         Environment: SUSE11 SP1, Cassandra 2.1.2, java version "1.7.0_55".
> 4 node cluster, vnode = 1, replication = 2
>            Reporter: Kevin Ye
>            Assignee: Aleksey Yeschenko
> I was doing counter test (first +100 several times, then -33) on a 4 nodes cluster while
below log appear at 2 nodes.There is no concurrent access to same counter.
> WARN  [CompactionExecutor:757] 2015-02-02 13:02:33,375 - invalid
global counter shard detected; (9cca9262-934a-4275-963b-66802471b0c2, 1, -33) and (9cca9262-934a-4275-963b-66802471b0c2,
1, 100) differ only in count; will pick highest to self-heal on compaction
> Anyone has encounter this problem? I thought Cassandra 2.1.2 had solved this counter
problem, but it appeared.

This message was sent by Atlassian JIRA

View raw message