incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Schuller <peter.schul...@infidyne.com>
Subject Re: Best way to detect/fix bitrot today?
Date Wed, 09 Feb 2011 06:06:11 GMT
> I should have clarified we have 3 copies, so in that case as long as 2 match
> we should be ok?

As far as I can think of, no. Whatever the reconciliation of two
columns results in, is what the cluster is expected to converge to. So
in the case of identical keys and mismatched values, tie breaking is
the deciding factor. There is no "global" comparison/voting process
between all nodes in the replicate set for the row.

> Even if there were checksumming at the SStable level, I assume it has to
> check and report these errors on compaction (or node repair)?

I believe that it would work minimally to just skip it (regular repair
would do the rest). However that said, there may be reasons to want to
do more. For example, if you have a cluster where you are relying on
QUORUM consistency then silently dropping data actively discovered to
be corrupt could be considered a consistency violation.

> I have seen some JIRA open on these issues ( 47 and 1717), but if I need
> something today, a read repair ( or a node repair) is the only viable
> option?

repair is needed anyway (unless you're use case is very unusual; no
deletes, no updates to pre-existing rows). But again to be clear,
neither repair nor read repair is primarily intended to address
arbitrary data corruption but rather to reach eventual consistency in
the cluster (after writes were dropped, a node went down, etc).

-- 
/ Peter Schuller

Mime
View raw message