[
https://issues.apache.org/jira/browse/CASSANDRA-9742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14617696#comment-14617696
]
Jonathan Ellis edited comment on CASSANDRA-9742 at 7/8/15 12:07 AM:
--------------------------------------------------------------------
My reasoning was, at a high level, that what the operator cares about is "make
sure this node has the data on it, that it should have." Validating checksums
is part of that, but comparing with other replicas is too.
On the other hand, sstables corrupted from hardware problems are a lot more
rare than unreplicated data. So maybe insisting that we check for the former
every time we do the latter is not the right call.
was (Author: jbellis):
I thought about that, and I thought about it again after your comment, but I'm
still leaning towards one command.
My reasoning is, at a high level, what the op cares about is "make sure this
node has the data on it, that it should have." Validating checksums is part of
that, but comparing with other replicas is too.
> Nodetool verify
> ---------------
>
> Key: CASSANDRA-9742
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9742
> Project: Cassandra
> Issue Type: New Feature
> Components: Tools
> Reporter: Jonathan Ellis
> Fix For: 3.x
>
>
> We introduced incremental repair in 2.1 but it is difficult to make that the
> default without unpleasant surprises for incautious users.
> Additionally, while we now store sstable checksums, we leave verification to
> the user.
> I propose introducing a new command, {{nodetool verify}}, that would address
> both of these.
> Default operation would be to do an incremental repair, plus validate
> checksums on *all* sstables (not just unrepaired ones). We could also have
> --local mode (checksums only) and --full (classic repair).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
