Sweet. Jonathan, I patched in your change and no longer see a read
repair for every quorum read in the debug logs. I also reran a load
test consisting of only simple read operations, and my quorum read
throughput has doubled now that the extraneous read repairs aren't
occurring. This makes sense
Since JIRA is mostly dead right now, here is the patch to test against 0.4.
On Mon, Sep 28, 2009 at 4:30 PM, Edmond Lau wrote:
> On Fri, Sep 25, 2009 at 8:10 PM, Jonathan Ellis wrote:
>> No, you're mixing two related concepts.
>>
>> When you do a quorum read it will fetch the actual data from on
On Fri, Sep 25, 2009 at 8:10 PM, Jonathan Ellis wrote:
> No, you're mixing two related concepts.
>
> When you do a quorum read it will fetch the actual data from one
> replica and do digest reads from the others. If the data from the one
> does not match the hash from the others, then you have th
No, you're mixing two related concepts.
When you do a quorum read it will fetch the actual data from one
replica and do digest reads from the others. If the data from the one
does not match the hash from the others, then you have the
digestmismatchexception Edmond is seeing and read repair is per
This is a known issue, and we should perhaps open a JIRA on it.
The original Dynamo approach was to have 3 mechanisms --
HintedHandoff, read-repair, and Merk trees to guarantee convergence
(eventual consistency). Cassandra only has the first two. There are
some corner cases where hinted-handoff alo
I have a 3 node cluster with a replication factor of 2, running on 0.4
RC1. I've set both my read and write consistency levels to use a
quorum.
I'm observing that quorum reads keep invoking read repair and log
DigestMismatchExceptions from the StorageProxy. Obviously, this
significantly reduces
