[
https://issues.apache.org/jira/browse/CASSANDRA-5791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14620541#comment-14620541
]
Jonathan Ellis commented on CASSANDRA-5791:
-------------------------------------------
bq. without the marking-unrepaired part, incremental repair does not handle the
bitrot case formerly handled by non-incremental repair
The problem I'm bringing up is that even *with* marking unrepaired, incremental
repair does not handle bitrot. What we'd need to do is mark unrepaired the
exact sstables that contain the same data as the bitrotted one, on the other
replicas, which is impossible.
Incremental repair syncs up all the replicas but it doesn't "repair" when we
lose data that we once had but don't anymore, that's the tradeoff. So for
bitrot, like other data loss, you need full repair. (But, we can do better
here than a typical human would, by only doing a full repair on the range
covered by the corrupt sstable.)
> A nodetool command to validate all sstables in a node
> -----------------------------------------------------
>
> Key: CASSANDRA-5791
> URL: https://issues.apache.org/jira/browse/CASSANDRA-5791
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: sankalp kohli
> Assignee: Jeff Jirsa
> Priority: Minor
> Fix For: 2.2.0 beta 1
>
> Attachments: cassandra-5791-20150319.diff,
> cassandra-5791-patch-3.diff, cassandra-5791.patch-2
>
>
> CUrrently there is no nodetool command to validate all sstables on disk. The
> only way to do this is to run a repair and see if it succeeds. But we cannot
> repair the system keyspace.
> Also we can run upgrade sstables but that re writes all the sstables.
> This command should check the hash of all sstables and return whether all
> data is readable all not. This should NOT care about consistency.
> The compressed sstables do not have hash so not sure how it will work there.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
