cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David King <>
Subject Re: Is it possible to achieve "sticky" request routing?
Date Tue, 05 Apr 2016 16:32:51 GMT
Many C* versions back I did this by writing a custom snitch. This was to maximise use of the
row cache but had the effect of pinning requests for a key to a given server. It sounds like
you want to do the same thing but ignoring the key. In more modern reversions I believe this
may be done as a load balancing policy.

I don't have the code handy but it was only a few dozen lines of Java, mostly boilerplate.
IIRC the interface method just asks you to sort a list of IP addresses in your order of preference.

Note that this only really does anything for the ONE consistency level. In any other level
you'll end up hitting all 3 servers anyway.

> On 02 Apr 2016, at 20:06, Mukil Kesavan <> wrote:
> Hello,
> We currently have 3 Cassandra servers running in a single datacenter with a replication
factor of 3 for our keyspace. We also use the SimpleSnitch wiith DynamicSnitching enabled
by default. Our load balancing policy is TokenAwareLoadBalancingPolicy with RoundRobinPolicy
as the child. This overall configuration results in our client requests spreading equally
across our 3 servers.
> However, we have a new requirement where we need to restrict a client's requests to a
single server and only go to the other servers on failure of the previous server. This particular
use case does not have high request traffic.
> Looking at the documentation the options we have seem to be:
> 1. Play with the snitching (e.g. place each server into its own DC or Rack) to ensure
that requests always go to one server and failover to the others if required. I understand
that this may also affect replica placement and we may need to run nodetool repair. So this
is not our most preferred option.
> 2. Write a new load balancing policy that also uses the HostStateListener for tracking
host up and down messages, that essentially accomplishes "sticky" request routing with failover
to other nodes.
> Is option 2 the only clean way of accomplishing our requirement?
> Thanks,
> Micky

View raw message