I’ve had a few use cases for downgrading consistency over the years. If you’re showing a customer dashboard w/ some Ad summary data, it’s great to be right, but showing a number that’s close is better than not being up.
> On Oct 6, 2017, at 1:32 PM, Jeff Jirsa <[email protected]> wrote: > > I think it was Brandon that used to make a pretty compelling argument that > downgrading consistency on writes was always wrong, because if you can > tolerate the lower consistency, you should just use the lower consistency > from the start (because cassandra is still going to send the write to all > replicas, anyway). > > On Fri, Oct 6, 2017 at 12:51 PM, Jim Witschey <[email protected] > <mailto:[email protected]>> wrote: > > Modern client drivers also have ways to “downgrade” the CL of requests, in > > case they fail. E.g. for the Java driver: > > http://docs.datastax.com/en/latest-java-driver-api/com/datastax/driver/core/policies/DowngradingConsistencyRetryPolicy.html > > > > <http://docs.datastax.com/en/latest-java-driver-api/com/datastax/driver/core/policies/DowngradingConsistencyRetryPolicy.html> > > Quick note from a driver dev's perspective: Mark, yours sounds like a > bad use case for a downgrading retry policy. If your cluster has an RF > of 2, and your app requires CL.QUORUM, a downgrading policy will, e.g. > try at CL.QUORUM and downgrade below your required CL; or try at > CL.ALL, then fail and downgrade to CL.QUORUM or an equivalent, which > is what your app needs in the first place. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > <mailto:[email protected]> > For additional commands, e-mail: [email protected] > <mailto:[email protected]> > >
