cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Blake Eggleston <beggles...@apple.com>
Subject Re: Does NTP affects LWT's ballot UUID?
Date Wed, 11 Oct 2017 14:53:24 GMT
Since the UUID is used as the ballot in a paxos instance, if it goes backwards in time, it
will be rejected by the other replicas (if there is a more recent instance), and the proposal
will fail. However, after the initial rejection, the coordinator will try again with the most
recently seen ballot +1, which should succeed (unless another coordinator has started a proposal
with a higher ballot in the meantime).

On October 10, 2017 at 1:04:22 AM, Daniel Woo (daniel.y.woo@gmail.com) wrote:

Hi DuyHai,

Thanks, and that's exactly what I am asking, if NTP goes backward. Actually NTP often does
that because clock drift is inevitable.

On Tue, Oct 10, 2017 at 3:13 PM, DuyHai Doan <doanduyhai@gmail.com> wrote:
The ballot UUID is obtained using QUORUM agreement between replicas for a given partition
key and we use this TimeUUID ballot as write-time for the mutation.

The only scenario where I can see a problem is that NTP goes backward in time on a QUORUM
of replicas, which would break the contract of monotonicity. I don't know how likely this
event is ...

On Tue, Oct 10, 2017 at 9:07 AM, Daniel Woo <daniel.y.woo@gmail.com> wrote:
Hi guys,

The ballot UUID should be monotonically increasing on each coordinator, but the UUID in cassandra
is version 1 (timestamp based), what happens if the NTP service adjusts system clock while
a two phase paxos prepare/commit is in progress?

--
Thanks & Regards,
Daniel




--
Thanks & Regards,
Daniel

Mime
View raw message