Re: Need help to review a serializability implementation for MySQL Cluster

[Alex Ou]

There has been an incident with NIST's atomic clocks that renders US official time to be about 5 microseconds slower lately: https://www.npr.org/2025/12/21/nx-s1-5651317/colorado-us-official-time-microseconds-nist-clocks. I'd like take this opportunity to explore a bit whether this kind of events could affect the serializability implementations discussed in my work.

Let's start with TiDB. In TiDB, albeit the distributed clock algorithm can be affected both in the calibration stage and timestamp service stage, it only alters the execution path in the algorithm comparing with an accurate wall clock; the key property that it returns timestamps in an increasing order so that the proof of serializability can go through is not changed. Please refer to subsection D.4 for the details.

For Google's Spanner, it uses its own atomic clocks so this incident doesn't affect its operation at all. In the case that its atomic clocks or GPS clocks are lagging behind, its TrueTime distributed clock algorithm can still guarantee the real time lies within the interval it returns, which is the key to proving it is serializable in subsection D.1.
In the CockroachDB case, a lag of 5 microseconds probably only causes the cluster to operate with a slightly different Epsilon(see subsection D.3 for the details). By default, the lag need to be as large as 400 milliseconds for the cluster to shut down that sluggish node: https://www.cockroachlabs.com/docs/stable/operational-faqs#what-happens-when-node-clocks-are-not-properly-synchronized. When that happens, serializability holds before, during and after this shutdown.

NDB Cluster doesn't use a distributed clock and OceanBase's is a logical one. Serializability is by no means affected by this kind of events.

As we can see, modern database clusters are resilient to incidents like this one since the physical clock is masked up somehow. For systems that only use physical clock for timestamps, it might end up that the application developer need to deal with it at second tier and that usually implies heavy lifting.