> 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
