Following https://issues.apache.org/jira/browse/CASSANDRA-9131. It is very interesting to track how the timestamp has moved from the user, to the server, then back to the user quasi the driver.
Next we will be accounting for the earths slowing rotation as the ice caps melt :) https://www.uwgb.edu/dutchs/PSEUDOSC/IceCaps.HTM On Thu, Oct 27, 2016 at 1:18 PM, Anuj Wadehra <anujw_2...@yahoo.co.in> wrote: > Hi Ben, > > Thanks for your reply. We dont use timestamps in primary key. We rely on > server side timestamps generated by coordinator. So, no functions at > client side would help. > > Yes, drifts can create problems too. But even if you ensure that nodes are > perfectly synced with NTP, you will surely mess up the order of updates > during the leap second(interleaving). Some applications update same column > of same row quickly (within a second ) and reversing the order would > corrupt the data. > > I am interested in learning how people relying on strict order of updates > handle leap second scenario when clock goes back one second(same second is > repeated). What kind of tricks people use to ensure that server side > timestamps are monotonic ? > > As per my understanding NTP slew mode may not be suitable for Cassandra as > it may cause unpredictable drift amongst the Cassandra nodes. Ideas ?? > > > Thanks > Anuj > > > > Sent from Yahoo Mail on Android > <https://overview.mail.yahoo.com/mobile/?.src=Android> > > On Thu, 20 Oct, 2016 at 11:25 PM, Ben Bromhead > <b...@instaclustr.com> wrote: > http://www.datastax.com/dev/blog/preparing-for-the-leap-second gives a > pretty good overview > > If you are using a timestamp as part of your primary key, this is the > situation where you could end up overwriting data. I would suggest using > timeuuid instead which will ensure that you get different primary keys even > for data inserted at the exact same timestamp. > > The blog post also suggests using certain monotonic timestamp classes in > Java however these will not help you if you have multiple clients that may > overwrite data. > > As for the interleaving or out of order problem, this is hard to address > in Cassandra without resorting to external coordination or LWTs. If you are > relying on a wall clock to guarantee order in a distributed system you will > get yourself into trouble even without leap seconds (clock drift, NTP > inaccuracy etc). > > On Thu, 20 Oct 2016 at 10:30 Anuj Wadehra <anujw_2...@yahoo.co.in> wrote: > >> Hi, >> >> I would like to know how you guys handle leap seconds with Cassandra. >> >> I am not bothered about the livelock issue as we are using appropriate >> versions of Linux and Java. I am more interested in finding an optimum >> answer for the following question: >> >> How do you handle wrong ordering of multiple writes (on same row and >> column) during the leap second? You may overwrite the new value with old >> one (disaster). >> >> And Downtime is no option :) >> >> I can see that CASSANDRA-9131 is still open.. >> >> FYI..we are on 2.0.14 .. >> >> >> Thanks >> Anuj >> > -- > Ben Bromhead > CTO | Instaclustr <https://www.instaclustr.com/> > +1 650 284 9692 > Managed Cassandra / Spark on AWS, Azure and Softlayer > >
