cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Yeschenko (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CASSANDRA-9947) nodetool verify is broken
Date Fri, 30 Oct 2015 16:18:27 GMT

     [ https://issues.apache.org/jira/browse/CASSANDRA-9947?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Aleksey Yeschenko updated CASSANDRA-9947:
-----------------------------------------
    Component/s: Tools

> nodetool verify is broken
> -------------------------
>
>                 Key: CASSANDRA-9947
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-9947
>             Project: Cassandra
>          Issue Type: Bug
>          Components: Tools
>            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)

Mime
View raw message