From user-return-60244-archive-asf-public=cust-asf.ponee.io@cassandra.apache.org Fri Mar 9 03:40:33 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id 8B97C18064C for ; Fri, 9 Mar 2018 03:40:32 +0100 (CET) Received: (qmail 87249 invoked by uid 500); 9 Mar 2018 02:40:29 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 87238 invoked by uid 99); 9 Mar 2018 02:40:29 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 09 Mar 2018 02:40:29 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id E1572C0111 for ; Fri, 9 Mar 2018 02:40:28 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.998 X-Spam-Level: * X-Spam-Status: No, score=1.998 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd4-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=scylladb-com.20150623.gappssmtp.com Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id DGsaU9F8KoA5 for ; Fri, 9 Mar 2018 02:40:26 +0000 (UTC) Received: from mail-qk0-f176.google.com (mail-qk0-f176.google.com [209.85.220.176]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id B03B75F254 for ; Fri, 9 Mar 2018 02:40:25 +0000 (UTC) Received: by mail-qk0-f176.google.com with SMTP id d206so2137286qkb.3 for ; Thu, 08 Mar 2018 18:40:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=scylladb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=NWKVkTZlpxkTxtQfOkkeNxyKGVCc7oI7OZ/q8GvVN/c=; b=HkNNHgHr4U+MDDCjNphi3F7ji503wnkthNc/atUbCwkqL6RWHRxqDih4FUc0LFaDRk HNHiATJgEJXjVhle/2zMyCYi6SKMegLvmpn4krKuGrMMyDh/AEPlN7jIuASnENyz0us5 gEdC0IS4PBjm2wBLekL7J/cMRk/3M70js6NPe+REOXyTdoZkwJhkze/0v1BC9g/OLE84 b2loNjL6P0T9ga8gU5ShGKDRFCAqljHXMxskOIj8r9SKIA5ThbeuK2npcCGsBtf68Bgd ozZfyp0/NV6rdOIJ14evaqlZnh2GQkCpXpfLThM5sM2NSF5u/MpdrMG/7rPTTCqJGW7d z19g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=NWKVkTZlpxkTxtQfOkkeNxyKGVCc7oI7OZ/q8GvVN/c=; b=r7mlzObLfVwvopQaNTXiawEDkr9+AXnKO55YAr8ja4MRUjV9LbSIf1IpH87EXmjtsH dYr+97SkidZez4A+RXOTPsFxO0FVSpzm7f6J848TaOuoUemHsqZxQ97Ka8jJU6tzefmE 4Iub+6zXZ1YIIXGNArmLWRGYlOcbP7y1Yt85yk4ttSBbBDY30MmahKfrM7Gj0yu7wZBC 9SOZ8+mMsrll5dzMkBAeb4qgO85oTJsQ/Xj6OY2Ui7i0jyh44jlLHWNXnd7ilCMNxv1U gHl52XpHHL9nDW7MqImO2KrauHq0xx6NqkXBMGwFYMNlB5VI8AdGN3iay8k3JvhZQogs Y1EA== X-Gm-Message-State: AElRT7GfSZsnuLyOifVljk9XJafXyRapvvhEICjddPH8vIeGkLWoNxSD rOBYJoSvc0FX25pjDMVf2kKwIy4bXzAlgxC0CJB2bQfs X-Google-Smtp-Source: AG47ELsxFKHviKtY2dkcKlIbwtua4I7A9lyVxMMTA8cLtdlAscRQW1iQmOCb8WtKbkex+LNfcNOBnRoH01UlRmxOnbw= X-Received: by 10.55.112.133 with SMTP id l127mr44115732qkc.224.1520563224353; Thu, 08 Mar 2018 18:40:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.35.55 with HTTP; Thu, 8 Mar 2018 18:39:43 -0800 (PST) In-Reply-To: References: <60bc6b7d-b6b2-f244-f416-a2c4056f52b2@pbandjelly.org> From: Dor Laor Date: Thu, 8 Mar 2018 18:39:43 -0800 Message-ID: Subject: Re: Amazon Time Sync Service + ntpd vs chrony To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary="001a114ff454d8b3b40566f1b647" --001a114ff454d8b3b40566f1b647 Content-Type: text/plain; charset="UTF-8" Agree! When using client timestamp, NTP should be running on them as well. On Thu, Mar 8, 2018 at 6:24 PM, Jeff Jirsa 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 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 > 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.c >> om/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 >> 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-t >>> ime-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-unsubscribe@cassandra.apache.org >>> For additional commands, e-mail: user-help@cassandra.apache.org >>> >>> -- >> >> >> *Ben Slater* >> >> *Chief Product Officer * >> >> >> >> >> >> Read our latest technical blog posts here >> . >> >> 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. >> > > --001a114ff454d8b3b40566f1b647 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Agree! When using client timestamp, NTP should be running = on them as well.


On Thu, Mar 8, 2018 at 6:24 PM, Jeff Jirsa <jjirsa@gmai= l.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 m= atters.

--=C2=A0
Jeff Jirsa

On Mar 8, 2018,= at 6:18 PM, Dor Laor <dor@scylladb.com> wrote:

While NTP on the servers is important, make sure tha= t 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 a= t 2:12 PM, Ben Slater <ben.slater@instaclustr.com> = wrote:
It is important t= o make sure you are using the same NTP servers across your cluster - we use= d to see relatively frequent NTP issues across our fleet using default/publ= ic NTP servers until (back in 2015) we implemented our own NTP pool (see=C2= =A0https://www.instaclustr.com/apache-cassandra-synch= ronization/=C2=A0which references some really good and detailed po= sts from logentries.com= on the potential issues).

Cheers
Ben

On Fri, 9 Mar 2018 at 02:07 Michael Shuler <michael@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<= br> 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/A= WSEC2/latest/UserGuide/set-time.html).
> It's stated there that chrony is faster / more precise than ntpd.<= br> >
> Nothing to say correct time sync configuration is very important for a= ny
> 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?<= br> > Are there any chrony best-practices/custom settings for C* setups?
>
> Thanks,
> Kyrill
>


-----------------------------------------------------------------= ----
To unsubscribe, e-mail: user-unsubscribe@cassandra.apache.org
For additional commands, e-mail: user-help@cassandra.apache.org

--

Ben Slater<= br class=3D"m_-675479134566984474m_5244623309075488371gmail_msg">Chief Product Officer

=C2=A0=C2=A0=C2=A0=C2= =A0

Read ou= r latest technical blog posts=C2=A0here.

This email has been sent on behalf o= f=C2=A0Instaclustr Pty. Limited (Australia) and=C2=A0Instaclustr Inc (USA).=

This email and any atta= chments may=C2=A0contain confidential and legally privileged=C2=A0informati= on.=C2=A0 If you are not the intended=C2=A0recipient, do not copy or disclo= se its=C2=A0content, but please reply to this email=C2=A0immediately and hi= ghlight the error to the=C2=A0sender and then immediately delete the=C2=A0m= essage.



--001a114ff454d8b3b40566f1b647--