[
https://issues.apache.org/jira/browse/CASSANDRA-4417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13452016#comment-13452016
]
Charles Brophy commented on CASSANDRA-4417:
-------------------------------------------
Yes, we operate under a heavy write load and we do have frequent compaction as
a result, but under normal conditions I never see this exception - or at least
it doesn't happen often enough for me to catch. Following a repair, however,
it's a guarantee for us. Could it be as simple as:
* the two servers are participants in the same key-range replicant and the
sstables contain the same key/row/column references
* the process of streaming repair is sending a set of key/row/column references
to the requestor in the same sstable as the out-of-sync data it's already aware
of via repair
* Compaction finds the duplicate references in the recently received sstables -
they're basically the other replicant's copies of that data
It seems that the act of sending the sstables from one server to the other when
both are replicants of the same key range would be expected to result in
duplicate references. I'm probably way off.
> 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
