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 - al...@thelastpickle.com France The Last Pickle - Apache Cassandra Consulting http://www.thelastpickle.com 2017-09-29 13:44 GMT+01:00 Sylvain Lebresne <sylv...@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-unsubscr...@cassandra.apache.org > For additional commands, e-mail: user-h...@cassandra.apache.org > >