[
https://issues.apache.org/jira/browse/CASSANDRA-5791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14327399#comment-14327399
]
Branimir Lambov commented on CASSANDRA-5791:
--------------------------------------------
Looks mostly good, I have a few questions about things you don't currently
treat as failures and a couple of nits:
[Verifier.java
104|https://github.com/jeffjirsa/cassandra/commit/7367b2fd88fe025006c783d6e07c8a4890690f0a#diff-fa9585e54785eef42f1245aceda15806R104]:
Should we not mutateRepaired on missing digest?
[Verifier.java
130|https://github.com/jeffjirsa/cassandra/commit/7367b2fd88fe025006c783d6e07c8a4890690f0a#diff-fa9585e54785eef42f1245aceda15806R130]:
If the first position in the index is always supposed to be 0, doesn't a
different value signify an index corruption? Why assert instead of treating
this as a validation failure?
[Verifier.java
202|https://github.com/jeffjirsa/cassandra/commit/7367b2fd88fe025006c783d6e07c8a4890690f0a#diff-fa9585e54785eef42f1245aceda15806R202]
and
[168|https://github.com/jeffjirsa/cassandra/commit/7367b2fd88fe025006c783d6e07c8a4890690f0a#diff-fa9585e54785eef42f1245aceda15806R168]:
You only warn on invalid index entries, but still use
{{nextRowPositionFromIndex}} for walking the data-- shouldn't then an invalid
index be also treated as a validation failure?
[Verifier.java
196|https://github.com/jeffjirsa/cassandra/commit/7367b2fd88fe025006c783d6e07c8a4890690f0a#diff-fa9585e54785eef42f1245aceda15806R196]:
Is this a good nor bad row? Shouldn't order violation be a validation error?
[Verifier.java
227|https://github.com/jeffjirsa/cassandra/commit/7367b2fd88fe025006c783d6e07c8a4890690f0a#diff-fa9585e54785eef42f1245aceda15806R227]:
Is this code reachable? The only place that sets badRows also throws.
[StandaloneVerifier.java
128|https://github.com/jeffjirsa/cassandra/commit/7367b2fd88fe025006c783d6e07c8a4890690f0a#diff-85d9fb1ffe8c937029e4ec870f662f6fR128]:
Should we stop on the first error? If there are more problems with the data
wouldn't we want to mark all ranges as unrepaired?
[sstableverify.bat
23|https://github.com/jeffjirsa/cassandra/commit/7367b2fd88fe025006c783d6e07c8a4890690f0a#diff-05cb8af4cf28268cb3ca58e70e47da22R23]:
I'd remove the possibility to specify {{CASSANDRA_MAIN}} to avoid unexpected
behaviour for people who might have it set for other purposes. Put the class
name directly into the command as in {{nodetool.bat}}.
[DataIntegrityMetadata.java
130|https://github.com/jeffjirsa/cassandra/commit/7367b2fd88fe025006c783d6e07c8a4890690f0a#diff-be889b1991c498fde94c039b5e327269R130]:
Why not just use {{while (true)}} with {{break}} in the validate loop?
[Component.java
50|https://github.com/jeffjirsa/cassandra/commit/7367b2fd88fe025006c783d6e07c8a4890690f0a#diff-2292395ba109e6df9e1650745810d30aR50]:
Update comment too.
[NodeTool.java
1313|https://github.com/jeffjirsa/cassandra/commit/7367b2fd88fe025006c783d6e07c8a4890690f0a#diff-1c11f86cc8881893cd6d369ffc23a809R1313]:
Change the error message (flush->verification).
> 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
> Attachments: 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)
