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

["Grant Henke (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/KUDU-2435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Grant Henke resolved KUDU-2435.
-------------------------------
    Fix Version/s: NA
       Resolution: Cannot Reproduce

> 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
>             Fix For: NA
>
>
> 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
(v8.3.4#803005)