4 ms·
There is, in fact, a TL;DR at the end: > If your distributed database relies on clocks to pick a winner, you’d better have rock-solid time synchronization, and
by RickHull 13y ago
There is, in fact, a TL;DR at the end:
> If your distributed database relies on clocks to pick a winner, you’d better have rock-solid time synchronization, and even then, it’s unlikely your business needs are served well by blindly selecting the last write that happens to arrive.
- sseveran 13y agoIn fact I would recommend GPS calibrated hardware clocks with PTP.
- donavanm 13y agoAs last summers negative leap second fiascos demonstrated even a trusted source isnt enough.
- oh_sigh 13y agoThey are when you know that the leap-(nanosecond/second/minute/day) is coming up. When you know it is coming, you can "smear" the time difference over, let's say, the entire year, so when it happens, every system behaves correctly.
- marshray 13y agoThe point is not that time synchronization is inherently bad, only that it's usually not the correct thing for a distributed database to resolve update conflicts with.
- sseveran 13y agoYes I completely agree. I fail to see how anyone would think that using a clock as a source of truth in a distributed system would be in anyway a good idea. As far as PTP it would be too expensive to deploy at large scale which was some of the motivation (i believe) behind truetime.
- marshray 13y agoTo be fair, time was considered to provide a pretty universal total ordering up until fairly recently, i.e., 1903.
- duaneb 13y agoOk, google.