[
https://issues.apache.org/jira/browse/CASSANDRA-9947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14977114#comment-14977114
]
Jeff Jirsa edited comment on CASSANDRA-9947 at 10/27/15 8:38 PM:
-----------------------------------------------------------------
The intent behind marking it as unrepaired was to allow other nodes to repair
this data inbound, though it does make sense that by doing so, we'll also
potentially pollute that corrupt data out to other replicas. Issuing a scrub
may not be the right fix, either - a single bit flip in an uncompressed table
will scrub just fine, and nothing will happen except you'll write a new
checksum and lose knowledge of the fact that the bit-flip happened.
Maybe the limitation here is that we have effectively 2 states - repaired and
unrepaired - when we need a third - corrupt - so we can force this local node
to repair its range, without using that sstable as a source for outgoing repair
streams?
Maybe the right thing to do is just trigger disk failure policy and let the
operator decide what to do with it? Then they can offline scrub and throw away
data from compressed tables, or delete uncompressed and let it be repaired.
was (Author: jjirsa):
The intent behind marking it as unrepaired was to allow other nodes to repair
this data inbound, though it does make sense that by doing so, we'll also
potentially pollute that corrupt data out to other replicas. Issuing a scrub
may not be the right fix, either - a single bit flip in an uncompressed table
will scrub just fine, and nothing will happen except you'll write a new
checksum and lose knowledge of the fact that the bit-flip happened.
Maybe the limitation here is that we have effectively 2 states - repaired and
unrepaired - when we need a third - corrupt - so we can force this local node
to repair its range, without using that sstable as a source for outgoing repair
streams?
> nodetool verify is broken
> -------------------------
>
> Key: CASSANDRA-9947
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9947
> Project: Cassandra
> Issue Type: Bug
> Components: Core
> Reporter: Jonathan Ellis
> Priority: Critical
> Fix For: 2.2.x
>
>
> Raised these issues on CASSANDRA-5791, but didn't revert/re-open, so they
> were ignored:
> We mark sstables that fail verification as unrepaired, but that's not going
> to do what you think. What it means is that the local node will use that
> sstable in the next repair, but other nodes will not. So all we'll end up
> doing is streaming whatever data we can read from it, to the other replicas.
> If we could magically mark whatever sstables correspond on the remote nodes,
> to the data in the local sstable, that would work, but we can't.
> 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
> Additionally,
> * I'm not sure that keeping "extended verify" code around is worth it. Since
> the point is to work around not having a checksum, we could just scrub
> instead. This is slightly more heavyweight but it would be a one-time cost
> (scrub would build a new checksum) and we wouldn't have to worry about
> keeping two versions of almost-the-same-code in sync.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
