Hi Micky, The only issues I've seen personally with dropped updates due to even small amounts of time skew were ones I was able to fix by the judicious use of BatchStatements. This was particularly true with counter fields in the 2.0 release (i.e. before counters were fixed), but would also happen with different columns updated in separate statements. I'm not sure what your circumstances are for the lost updates, so I'm not sure if these will help. I'm only pointing it out because it was effective for my cases.
Steve On Tue, Apr 5, 2016 at 3:21 PM, Mukil Kesavan <weirdbluelig...@gmail.com> wrote: > John and Steve, > > We use QUORUM consistency for both READS and WRITES. So we won't have the > problem of having to pick the right server. The real reason we have this > requirement is because we run in a sometimes overloaded virtualized > environment that causes the servers to have non-trivial time drifts (tens > of milliseconds or a few seconds, even with NTP, which catches up slowly). > This particular client was seeing some updates being dropped silently by > Cassandra when it hit a server with an older local timestamp. They were > relying on server side timestamp generation. > > So they were exploring "sticky" routing as an option since the likelihood > of having monotonically increasing timestamps is higher if the client's > requests always go to a single server. They are aware of the problem of > disconnecting and reconnecting to a new server and have an application > level solution for this. They are also testing using client side timestamps > as well. We're just trying to explore all our options and their pros and > cons. > > Thanks! > > On Tue, Apr 5, 2016 at 1:31 PM, Jonathan Haddad <j...@jonhaddad.com> wrote: > >> Yep - Steve hit the nail on the head. The odds of hitting the right >> server with "sticky routing" goes down as your cluster size increases. You >> end up adding extra network hops instead of using token aware routing. >> >> Unless you're trying to do a coordinator tier (and you're not, according >> to your original post), this is a pretty bad idea and I'd advise you to >> push back on that requirement. >> >> On Tue, Apr 5, 2016 at 12:47 PM Steve Robenalt <sroben...@highwire.org> >> wrote: >> >>> 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 >>> >> > -- 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
