Uploaded image for project: 'Kudu'
  1. Kudu
  2. KUDU-2435

Consider non-fatal response to "Tried to update clock beyond the max. error"

    XMLWordPrintableJSON

    Details

    • Type: Improvement
    • Status: Open
    • Priority: Major
    • Resolution: Unresolved
    • Affects Version/s: 1.7.0
    • Fix Version/s: None
    • Component/s: server
    • Labels:
      None

      Description

      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:

      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.

      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.

        Attachments

          Activity

            People

            • Assignee:
              Unassigned
              Reporter:
              mpercy Mike Percy
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated: