cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <>
Subject [jira] Commented: (CASSANDRA-930) make RR chance configurable
Date Wed, 31 Mar 2010 21:06:27 GMT


Jonathan Ellis commented on CASSANDRA-930:

Turns out (I'd forgotten) we already have DatabaseDescriptor.getConsistencyCheck to control
turning it off entirely.  This is exposed in as config variable DoConsistencyChecksBoolean,
but this is undocumented in our sample config file.

So what we want to do is add a double to CFMetaData recording a chance from 0 to 1 of doing
the repair, parse this from the config file, and change the bool check to a randomized one
against this double.

(Remember keyspace <=> table in the source, and you can get the CF from a ReadCommand
via the QueryPath.)

> make RR chance configurable
> ---------------------------
>                 Key: CASSANDRA-930
>                 URL:
>             Project: Cassandra
>          Issue Type: Wish
>          Components: Core
>            Reporter: Jonathan Ellis
>            Priority: Minor
>             Fix For: 0.8
> Read load increases linearly with replication factor.  While this can be mitigated by
simply adding machines, it would also be nice to be able to configure on a per-CF basis the
chance of performing a read repair, so that particularly heavily read CFs could have a chance
of (say) 10% and seldom-used ones could continue to repair every time, i.e., chance of 100%.
 Thus, the "hot keys get repaired before waiting for anti-entropy to kick in" property gets
preserved, but you might see a few more reads serving old values than before.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message