Limits on Failover Latency in YugabyteDB Raft Leader Election

Goal

Determine whether YugabyteDB provides a guaranteed upper bound on the time taken to elect a new tablet leader after a node failure, and how that bound is reflected in the system logs.

Constraints

• The election timeout is a random value between raft_election_timeout_ms_min and raft_election_timeout_ms_max, configurable but not fully documented.
• Logs from yb-master and yb-tserver contain entries like Election timeout and Leader elected, but interpreting the timestamps requires mapping Raft log indices and terms.
• Cluster size, network latency, and partitioning can affect the observed election duration, yet the documentation does not specify a hard upper bound beyond the configured maximum.
• Behavior may differ between YugabyteDB 2.x and 3.x releases, especially regarding default timeout values and log verbosity.

Unresolved Questions

1. Is there a documented worst‑case failover latency that guarantees an upper bound on leader election time, beyond the configured raft_election_timeout_ms_max?
2. If no hard upper bound exists, how should operators interpret the variability observed in yb-master and yb-tserver logs when planning SLA‑level failover windows?
3. Does the random election timeout introduce a measurable probability distribution for failover latency that can be quantified or bounded in practice?