Nevermind, I just found this blog post, which answers my question - I can’t seem to delete this post. Sorry for the bother.
BTW, I think there is a typo in that blog post:
By disallowing any conflicts that flow against the timestamp-ordered direction, *acyclic* serializability graphs are impossible. ->
By disallowing any conflicts that flow against the timestamp-ordered direction, *cyclic* serializability graphs are impossible.
Hi Richard,
I’m glad you were able to find the answer to your question. Are there places in the docs where you think we could have made this more clear?
And thanks for the typo report, I’ve fixed it [removed link to private repo]
Thanks, I guess that’s a private repo.
When a node restarts or crashes, its HLC could end up going backward in time (because it has no data to initialize it with except golang’s time.Now(), so does it sleep for max_clock_skew seconds?
Even that may not be a strong enough guarantee because the node NTP time could be totally off. Suppose a node restarts and its NTP time is 1971 - how do we guarantee that it cannot receive writes until its NTP time is within max_clock_skew of the valid HLC time?
Yes, a node sleeps at startup for the maximum clock offset minus the amount of time its startup took.
If the clock is way off after a restart, we currently handle that the same way we do if it jumped backwards while the node was running: as soon as we detect this situation the node that is out of sync will commit suicide. We don’t have any extra check for clock offsets when the node is first starting.