[ https://issues.apache.org/jira/browse/CASSANDRA-9947?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14649199#comment-14649199 ]
Jonathan Ellis commented on CASSANDRA-9947: ------------------------------------------- IMO we should disable verify for 2.2.1 until we can rearchitect it since this is a nontrivial change. > 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)