[
https://issues.apache.org/jira/browse/CASSANDRA-8094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sam Tunnicliffe updated CASSANDRA-8094:
---------------------------------------
Assignee: Sam Tunnicliffe (was: Minh Do)
Fix Version/s: (was: 2.1.x)
3.x
Status: Patch Available (was: Open)
Making the read repair mutations contingent on a table property is simple in
itself. The rub is that the new property needs to be added to schema and
persisted somewhere in {{system_schema}}. If we did this for a major version
bump, then that would also be straightforward, just a new column in {{tables}}.
4.0 is some way off though, and a goal of the project is to make even major
version changes less significant events and to be able to do more in minor,
incremental releases.
Tactically, this ticket can be implemented by using {{TableParams.extensions}}
(introduced in CASSANDRA-9426) as a vessel for the new property, with a couple
of checks to ensure that it doesn't get unintentionally obliterated. I've
pushed a branch with this implementation & added a dtest
[here|https://github.com/beobal/cassandra-dtest/commits/8094]
I'm sure there's a more general solution that will allow the schema tables to
be modified in a less disruptive way, so I've also opened CASSANDRA-11382 as a
placeholder for that.
||branch||testall||dtest||
|[8094|https://github.com/beobal/cassandra/tree/8094]|[testall|http://cassci.datastax.com/view/Dev/view/beobal/job/beobal-8094-testall]|[dtest|http://cassci.datastax.com/view/Dev/view/beobal/job/beobal-8094-dtest]|
> Heavy writes in RangeSlice read requests
> ------------------------------------------
>
> Key: CASSANDRA-8094
> URL: https://issues.apache.org/jira/browse/CASSANDRA-8094
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Minh Do
> Assignee: Sam Tunnicliffe
> Labels: lhf
> Fix For: 3.x
>
>
> RangeSlice requests always do a scheduled read repair when coordinators try
> to resolve replicas' responses no matter read_repair_chance is set or not.
> Because of this, in low writes and high reads clusters, there are very high
> write requests going on between nodes.
> We should have an option to turn this off and this can be different than the
> read_repair_chance.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
