cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John Sumsion (JIRA)" <>
Subject [jira] [Created] (CASSANDRA-8169) Background bitrot detector to avoid client exposure
Date Wed, 22 Oct 2014 21:53:33 GMT
John Sumsion created CASSANDRA-8169:

             Summary: Background bitrot detector to avoid client exposure
                 Key: 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

View raw message