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?
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 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 >
Re: Does NTP affects LWT's ballot UUID?
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 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 > 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?
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@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 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 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
