[
https://issues.apache.org/jira/browse/HBASE-14070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16097545#comment-16097545
]
stack commented on HBASE-14070:
-------------------------------
Having to manage catch-up is 'known issue' that has had some consideration. If
skew too large or we are unable to catch-up given allotted logical time per ms,
let the RS just fail (in first implementation).
On Problem 1: this will just become a case of a server being off by 30 seconds
which currently results in a RS shutdown.
On Problem 2: yeah, should add in protection. We can do this in-the-small in
the time-engine unit tests?
On Problem 3: is not a problem?
> Hybrid Logical Clocks for HBase
> -------------------------------
>
> Key: HBASE-14070
> URL: https://issues.apache.org/jira/browse/HBASE-14070
> Project: HBase
> Issue Type: New Feature
> Reporter: Enis Soztutar
> Assignee: Amit Patel
> Attachments: HBASE-14070.master.001.patch,
> HybridLogicalClocksforHBaseandPhoenix.docx,
> HybridLogicalClocksforHBaseandPhoenix.pdf
>
>
> HBase and Phoenix uses systems physical clock (PT) to give timestamps to
> events (read and writes). This works mostly when the system clock is strictly
> monotonically increasing and there is no cross-dependency between servers
> clocks. However we know that leap seconds, general clock skew and clock drift
> are in fact real.
> This jira proposes using Hybrid Logical Clocks (HLC) as an implementation of
> hybrid physical clock + a logical clock. HLC is best of both worlds where it
> keeps causality relationship similar to logical clocks, but still is
> compatible with NTP based physical system clock. HLC can be represented in
> 64bits.
> A design document is attached and also can be found here:
> https://docs.google.com/document/d/1LL2GAodiYi0waBz5ODGL4LDT4e_bXy8P9h6kWC05Bhw/edit#
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
