[
https://issues.apache.org/jira/browse/CASSANDRA-8169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14180604#comment-14180604
]
Jason Brown commented on CASSANDRA-8169:
----------------------------------------
bitrot detection as a side effect of repair is/was a nice benefit, but we
shouldn't expect repair to be the only tool for error detection. Does scrub
already fit this bill?
> Background bitrot detector to avoid client exposure
> ---------------------------------------------------
>
> Key: CASSANDRA-8169
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8169
> Project: Cassandra
> Issue Type: New Feature
> Reporter: John Sumsion
>
> With a lot of static data sitting in SSTables, and with only a relatively
> small add/edit rate, incremental repair sounds very good. However, there is
> one significant cost to switching away from full repair.
> If/when bitrot corrupts an SSTable, there is nothing standing between a user
> query and a corruption/failure-response event except for the other replicas.
> This combined with a rolling restart or upgrade can make a token range
> non-writable via quorum CL.
> While you could argue that full repairs should be scheduled on a longer-term
> regular basis, I don't really care about all the repair overhead, I just want
> something that can run ahead of user queries whose only responsibility is to
> detect bitrot, so that I can replace nodes in an aggressive way instead of
> having it be a failure-response situation.
> This bitrot detector need not incur the full cross-cluster cost of repair,
> and so would be less of a burden to run periodically.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
