You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@kudu.apache.org by "Mike Percy (JIRA)" <ji...@apache.org> on 2018/05/09 00:51:00 UTC

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

Mike Percy created KUDU-2435:
--------------------------------

             Summary: 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


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)