cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Brown (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-8169) Background bitrot detector to avoid client exposure
Date Wed, 22 Oct 2014 21:59:34 GMT


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:
>             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

View raw message