Re: Proposal for deprecating/removing the read_repair_chance/dclocal_read_repair_chance table options

[Alain RODRIGUEZ <ar...@gmail.com>]

Hello Sylvain,

Here is my feedback on this:

Would +1 deprecating it in 3.11.x and removing in 4.0
>

+1, unless someone can present a solid use case indeed.

Lastly, if the consensus here ends up being that they can have their use in
> weird case and that we fill supporting those cases is worth confusing
> everyone else and maintaining that code, I would still suggest disabling
> them totally by default.


Definitely +1 here.

After 6 years operating Cassandra and a few distinct clusters, I just used
those options once. Back then hints and counters were broken, so I tried
setting repair chance to *1*. But it wasn't even working properly for some
reason as the values were not consistent at all, changing on each read.
Going to strong consistency level (LOCAL_QUORUM) on both reads and write
was the reliable way to go already by then (not fixing counters issues, but
that's in the past now :)).

All the other work around read repairs was to set it to 0 to prevent inter
data center exchanges or to prevent it from messing up to much with TWCS.
So yes more harmful than helpful I would say. It was even mentioned in the
talk "How not to use Cassandra", by Axel Liljencrantz (Spotify), 4 years
ago already: https://www.youtube.com/watch?v=0u-EKJBPrj8.

I cannot think about a use case were I would absolutely want to have these
settings.

Thanks for starting this topic and for the openness.

C*heers,
-----------------------
Alain Rodriguez - @arodream - alain@thelastpickle.com
France

The Last Pickle - Apache Cassandra Consulting
http://www.thelastpickle.com

2017-09-29 13:44 GMT+01:00 Sylvain Lebresne <sy...@datastax.com>:

> We are considering deprecating and them ultimately removing the 2
> table options: 'read_repair_chance' and 'dclocal_read_repair_chance'.
> The rational and much more details are on CASSANDRA-13910
> (https://issues.apache.org/jira/browse/CASSANDRA-13910), so I won't
> repeat it here.
>
> The goal of this email is to raise awareness of this intention for
> those that don't follow JIRA closely. In particular, if those options
> are really important to you, we'll love to hear more of why that is.
> In any case, if you have feedback, either answer this email or comment
> on the JIRA ticket.
>
> --
> Sylvain
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@cassandra.apache.org
> For additional commands, e-mail: user-help@cassandra.apache.org
>
>