I wouldn't 100% rely on your clients to generate timestamps (actually don't 100% rely on timestamps at all!) .
Clients tend to be stateless, scaled up and down, stopped, started, ntp takes time to skew a clock and they are more likely to be moved between hypervisor's in cloud environments etc. All these combine to give you more scenarios where clients have unreliable clocks that are not roughly in sync with each other. By far and large the worst time related bugs I've experienced are due to Cassandra clients having the wrong timestamp set for it's writetime. Of course this depends on what you are prioritising... relative accuracy of any given writetime on one row to any other given row or just respecting what the client thinks is right. On Thu, Mar 8, 2018, 21:24 Jeff Jirsa <jji...@gmail.com> wrote: > Clients can race (and go backward), so the more computer answer tends to > be to use LWT/CAS to guarantee state if you have a data model where it > matters. > > > -- > Jeff Jirsa > > > On Mar 8, 2018, at 6:18 PM, Dor Laor <d...@scylladb.com> wrote: > > While NTP on the servers is important, make sure that you use client > timestamps and > not server. Since the last write wins, the data generator should be the > one setting its timestamp. > > On Thu, Mar 8, 2018 at 2:12 PM, Ben Slater <ben.sla...@instaclustr.com> > wrote: > >> It is important to make sure you are using the same NTP servers across >> your cluster - we used to see relatively frequent NTP issues across our >> fleet using default/public NTP servers until (back in 2015) we implemented >> our own NTP pool (see >> https://www.instaclustr.com/apache-cassandra-synchronization/ which >> references some really good and detailed posts from logentries.com on >> the potential issues). >> >> Cheers >> Ben >> >> On Fri, 9 Mar 2018 at 02:07 Michael Shuler <mich...@pbandjelly.org> >> wrote: >> >>> As long as your nodes are syncing time using the same method, that >>> should be good. Don't mix daemons, however, since they may sync from >>> different sources. Whether you use ntpd, openntp, ntpsec, chrony isn't >>> really important, since they are all just background daemons to sync the >>> system clock. There is nothing Cassandra-specific. >>> >>> -- >>> Kind regards, >>> Michael >>> >>> On 03/08/2018 04:15 AM, Kyrylo Lebediev wrote: >>> > Hi! >>> > >>> > Recently Amazon announced launch of Amazon Time Sync Service >>> > ( >>> https://aws.amazon.com/blogs/aws/keeping-time-with-amazon-time-sync-service/ >>> ) >>> > and now it's AWS-recommended way for time sync on EC2 instances >>> > (https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/set-time.html). >>> > It's stated there that chrony is faster / more precise than ntpd. >>> > >>> > Nothing to say correct time sync configuration is very important for >>> any >>> > C* setup. >>> > >>> > Does anybody have positive experience using crony, Amazon Time Sync >>> > Service with Cassandra and/or combination of them? >>> > Any concerns regarding chrony + Amazon Time Sync Service + Cassandra? >>> > Are there any chrony best-practices/custom settings for C* setups? >>> > >>> > Thanks, >>> > Kyrill >>> > >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org >>> For additional commands, e-mail: user-h...@cassandra.apache.org >>> >>> -- >> >> >> *Ben Slater* >> >> *Chief Product Officer <https://www.instaclustr.com/>* >> >> <https://www.facebook.com/instaclustr> >> <https://twitter.com/instaclustr> >> <https://www.linkedin.com/company/instaclustr> >> >> Read our latest technical blog posts here >> <https://www.instaclustr.com/blog/>. >> >> This email has been sent on behalf of Instaclustr Pty. Limited >> (Australia) and Instaclustr Inc (USA). >> >> This email and any attachments may contain confidential and legally >> privileged information. If you are not the intended recipient, do not copy >> or disclose its content, but please reply to this email immediately and >> highlight the error to the sender and then immediately delete the message. >> > > -- Ben Bromhead CTO | Instaclustr <https://www.instaclustr.com/> +1 650 284 9692 Reliability at Scale Cassandra, Spark, Elasticsearch on AWS, Azure, GCP and Softlayer
