Alexey Serbin created KUDU-3084: ----------------------------------- Summary: 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
[~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)