[ 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