[
https://issues.apache.org/jira/browse/CASSANDRA-5791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14619966#comment-14619966
]
Robert Coli commented on CASSANDRA-5791:
----------------------------------------
{quote}
[...] so we mark sstables that fail verification as unrepaired? Because that's
not going to help much [...]
IMO what we should do is:
# scrub, because it's quite likely we'll fail reading from the sstable
otherwise and
# full repair across the data range covered by the sstable
{quote}
This is the wrinkle from the (otherwise duplicate of this ticket)
CASSANDRA-8703 :
{quote}
>From my understanding, if bitrot is detected (via eg the CRC on the read path)
>then all SSTables containing the corrupted range need to be marked unrepaired
>on all replicas. Per marcuse@IRC, the naive/simplest response would be to just
>trigger a full repair in this case.
{quote}
As an operator, my personal interest in 5791/8703 is that without the
marking-unrepaired part, incremental repair does not handle the bitrot case
formerly handled by non-incremental repair.
tl;dr - I am +1 to the above approach!
> 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)
