[jira] [Commented] (KUDU-2435) Consider non-fatal response to "Tried to update clock beyond the max. error"

["Mike Percy (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/KUDU-2435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16468248#comment-16468248 ] 

Mike Percy commented on KUDU-2435:
----------------------------------

Something else worth considering is the "zone" of skewedness where NTP considers the clock sufficiently synchronized to allow Kudu to start up, but the skew is too much for HybridTime to tolerate. Can we detect and more gracefully handle that situation?

> Consider non-fatal response to "Tried to update clock beyond the max. error"
> ----------------------------------------------------------------------------
>
>                 Key: KUDU-2435
>                 URL: https://issues.apache.org/jira/browse/KUDU-2435
>             Project: Kudu
>          Issue Type: Improvement
>          Components: server
>    Affects Versions: 1.7.0
>            Reporter: Mike Percy
>            Priority: Major
>
> Currently when one server is skewed, and it tries to replicate to other servers in a cluster, it can cause the rest of the servers in the cluster to crash with the following message:
> {code:java}
> F0428 05:27:23.480379 104613 raft_consensus.cc:1264] Check failed: _s.ok() Bad status: Invalid argument: Tried to update clock beyond the max. error.{code}
> We should consider alternative ways of handling this issue. Maybe the replicas can reject requests that would cause this condition until NTP has a chance to correct the clock of the offending server. We should also consider whether clock skew should be taken into account when doing leader elections... if a server is not within the max clock error of the voter then maybe the vote should be withheld.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)