[
https://issues.apache.org/jira/browse/CASSANDRA-4417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13477943#comment-13477943
]
Chris Herron commented on CASSANDRA-4417:
-----------------------------------------
bq. Unless you've been able to reproduce on a brand new cluster where the
commit log was set to batch from the beginning (in which case, if you have an
easy way to reproduce, that would be interesting to know)
In our test the affected Super CF is completely deleted and recreated - so in
that sense the commit log was set to batch from the beginning. Is that
equivalent?
This does reproduce for every test run. Unfortunately our test is non-trivial
to share. It involves heavy writes and moderate reads to counters, while
simultaneously running upgradesstables on all nodes upon multiple CF's
(including the affected one). Interestingly, the symptom does appear even
before compaction reaches the Super CF that's active during the test.
> invalid counter shard detected
> -------------------------------
>
> Key: CASSANDRA-4417
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4417
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Affects Versions: 1.1.1
> Environment: Amazon Linux
> Reporter: Senthilvel Rangaswamy
>
> Seeing errors like these:
> 2012-07-06_07:00:27.22662 ERROR 07:00:27,226 invalid counter shard detected;
> (17bfd850-ac52-11e1-0000-6ecd0b5b61e7, 1, 13) and
> (17bfd850-ac52-11e1-0000-6ecd0b5b61e7, 1, 1) differ only in count; will pick
> highest to self-heal; this indicates a bug or corruption generated a bad
> counter shard
> What does it mean ?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
