[
https://issues.apache.org/jira/browse/CASSANDRA-8169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Shuler resolved CASSANDRA-8169.
---------------------------------------
Resolution: Duplicate
> 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)
