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 <doanduy...@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....@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
