cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jon Haddad <...@jonhaddad.com>
Subject Re: Node failure
Date Fri, 06 Oct 2017 20:38:26 GMT
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 <jjirsa@gmail.com> 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 <jim.witschey@datastax.com <mailto:jim.witschey@datastax.com>>
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: user-unsubscribe@cassandra.apache.org <mailto:user-unsubscribe@cassandra.apache.org>
> For additional commands, e-mail: user-help@cassandra.apache.org <mailto:user-help@cassandra.apache.org>
> 
> 


Mime
View raw message