[
https://issues.apache.org/jira/browse/CASSANDRA-4417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13453537#comment-13453537
]
Omid Aladini commented on CASSANDRA-4417:
-----------------------------------------
{quote}
A simple "workaround" is to use batch commit log, but that has a potentially
important performance impact.
{quote}
I'm a bit confused why batch commit would solve the problem. If cassandra
crashes before the batch is fsynced, the counter mutations which it was the
leader for will still be lost although they might have been applied on other
replicas. The difference would be that the mutations won't be acknowledged to
the client, and since counters aren't idempotent, the client won't know weather
to retry or not. Am I missing something?
> 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
