There is no one size fits all but take a look at this scenario:
--------- T0 ---------- T1------------
Op0 Op1
Client Client
deletes writes Y to
cell X cell X
T0 < T1 in the real world.
When using client timestamp T0 clearly happens before T1.
If you use server timestamp, with Chrony, there is miliseconds difference:
https://chrony.tuxfamily.org/
So if Op0 was handled by S0 node and Op1 handles by S1 node
were time(S0) > time(S1) you get an empty cell in X.
Of course the same can happens when you use multiple clients issuing
multiple
operations but at least from the perspective of the single client logic
things are coherent.
On Thu, Mar 8, 2018 at 6:46 PM, Ben Bromhead <[email protected]> wrote:
> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]>
>> 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 <[email protected]>
>>> 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: [email protected]
>>>> For additional commands, e-mail: [email protected]
>>>>
>>>> --
>>>
>>>
>>> *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 <(650)%20284-9692>
> Reliability at Scale
> Cassandra, Spark, Elasticsearch on AWS, Azure, GCP and Softlayer
>
