[
https://issues.apache.org/jira/browse/KUDU-3084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Grant Henke updated KUDU-3084:
------------------------------
Labels: clock roadmap-candidate usability (was: clock)
> Multiple time sources with fallback behavior between them
> ---------------------------------------------------------
>
> Key: KUDU-3084
> URL: https://issues.apache.org/jira/browse/KUDU-3084
> Project: Kudu
> Issue Type: Improvement
> Components: master, tserver
> Reporter: Alexey Serbin
> Priority: Major
> Labels: clock, roadmap-candidate, usability
>
> [~tlipcon] suggested an alternative approach to configure and select
> HybridClock's time source.
> Kudu servers could maintain multiple time sources and switch between them
> with a fallback behavior. The default or preferred time source might be any
> of the existing ones (e.g., the built-in client), but when it's not
> available, another available time source is selected (e.g., {{system}} -- the
> NTP-synchronized local clock). Switching between time sources can be done:
> * only upon startup/initialization
> * upon startup/initialization and later during normal run time
> The advantages are:
> * easier deployment and configuration of Kudu clusters
> * simplified upgrade path from older releases using {{system}} time source to
> newer releases using {{builtin}} time source by default
> There are downsides, though. Since the new way of maintaining time source is
> more dynamic, it can:
> * mask various configuration or network issues
> * result in different time source within the same Kudu cluster due to
> transient issues
> * introduce extra startup delay
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
