[
https://issues.apache.org/jira/browse/CASSANDRA-4730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13678159#comment-13678159
]
Robert Coli commented on CASSANDRA-4730:
----------------------------------------
In Cassandra, the commitlog is streamable (CASSANDRA-3690). If you are
streaming your commitlog and your commitlog has become corrupt at a position
before the end as a result of on-disk corruption from (say..) cosmic rays,
there *is* an action you can take in response to this proposed error message :
restore the commitlog from before it became corrupt.
If your commitlog is corrupt, it is possible/likely that a replicated write has
been considered successful for ConsistencyLevel purposes but has been lost. If
so, repair is now required to be consistent. This proposed error message is
necessary to know that this repair is required.
If the checksum mismatch does not reliably indicate commitlog corruption, what
is its purpose?
I am skeptical that an operator exists who does not wish to know when the
mechanism which provides durability to his database is unable to provide
durability due to corruption, even when there is no action to take.
> CommitLogReplayer should report the bad CRC checksum in the log
> ---------------------------------------------------------------
>
> Key: CASSANDRA-4730
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4730
> Project: Cassandra
> Issue Type: Bug
> Affects Versions: 1.1.5
> Environment: Cassandra 1.1.5
> Reporter: Arya Goudarzi
>
> If commit log isn't fully fsynced, the record which fails the checksum is not
> replayed do this logic. It would be beneficial to log that as an error so
> that user can know easily what happened.
> "./src/java/org/apache/cassandra/db/commitlog/CommitLogReplayer.java" line
> 188 of 287 --65%-- col 54
--
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
