You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by Daniel Woo <da...@gmail.com> on 2017/10/10 07:07:04 UTC
Does NTP affects LWT's ballot UUID?
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
Re: Does NTP affects LWT's ballot UUID?
Posted by Blake Eggleston <be...@apple.com>.
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 <do...@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 <da...@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
Re: Does NTP affects LWT's ballot UUID?
Posted by Daniel Woo <da...@gmail.com>.
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 <do...@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 <da...@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
Re: Does NTP affects LWT's ballot UUID?
Posted by DuyHai Doan <do...@gmail.com>.
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 <da...@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
>