Aside from Jon's "why" question, I would point out that this only really works because you are running a 3 node cluster with RF=3. If your cluster is going to grow, you can't guarantee that any one server would have all records. I'd be pretty hesitant to put an invisible constraint like that on a cluster unless you're pretty sure it'll only ever be 3 nodes.
On Tue, Apr 5, 2016 at 9:34 AM, Jonathan Haddad <j...@jonhaddad.com> wrote: > Why is this a requirement? Honestly I don't know why you would do this. > > > On Sat, Apr 2, 2016 at 8:06 PM Mukil Kesavan <weirdbluelig...@gmail.com> > 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 >> > -- Steve Robenalt Software Architect sroben...@highwire.org <bza...@highwire.org> (office/cell): 916-505-1785 HighWire Press, Inc. 425 Broadway St, Redwood City, CA 94063 www.highwire.org Technology for Scholarly Communication
