3 ms·

Still digesting the talk. Did you have a look at cockroachdb (or their Blog) when thinking of your implementation?

• jorangreef 5y ago
  We looked to LMAX for the design, and to UW-Madison for our fault models, but appreciated how CockroachDB approached and cared about clock faults. However, our motivation for managing clock faults was not because we wanted to do leader leases. We don't risk stale reads so we don't do leader leases, i.e. where the leader can operate as a lone ranger without consensus from the cluster for a period of time. We're not comfortable with what could potentially go wrong when stale reads are allowed to become part of the fault model. The motivation for having some kind of clock fault tolerance was rather so that TigerBeetle can clamp the system time to cluster time for reasonably accurate transaction timestamps for auditing purposes, and for reliable timeouts of our two-phase commit ledger transfers so that liquidity is not locked up forever. In other words, the only reason we synchronize clocks across the cluster is so that a leader with a far-future clock can't push the cluster's monotonic clock out into the far future for unrealistic timestamps or to delay transaction timeouts (or expire them too early if a new leader's clock is stuck in the past).