Skip to content

Add support for custom election tick#9725

Open
LakshimiRam-073 wants to merge 1 commit into
dgraph-io:mainfrom
LakshimiRam-073:feature/custom-election-tick
Open

Add support for custom election tick#9725
LakshimiRam-073 wants to merge 1 commit into
dgraph-io:mainfrom
LakshimiRam-073:feature/custom-election-tick

Conversation

@LakshimiRam-073
Copy link
Copy Markdown

Description

This PR adds election-tick as a configurable sub-option to the existing --raft superflag for both Alpha and Zero nodes.

Currently, ElectionTick is hardcoded to 20 in conn/node.go:91 (equivalent to 2 seconds at the 100ms tick interval). This makes it impossible for operators to control leader election priority across nodes deployed in heterogeneous network topologies -- for example, nodes spread across different network segments with varying inter-node RTTs (1-2ms within the same segment vs. 10-50ms across segments), or nodes behind different network switches with asymmetric bandwidth, latency, and jitter characteristics.

Changes:

  1. worker/server_state.go — Added election-tick=20 to RaftDefaults string (preserves backward compatibility)
  2. conn/node.go — Read election-tick from x.WorkerConfig.Raft config instead of hardcoded value
  3. Validation — Added minimum bound check ensuring election-tick >= 10 * HeartbeatTick per etcd/raft library requirements

Use case: In deployments where Alpha nodes span different network segments with asymmetric latency, operators can now bias leadership toward low-latency nodes:

# Low-latency segment — fast election timeout (1-2s)
dgraph alpha --raft="idx=1; group=1; election-tick=10"

# High-latency segment — conservative timeout (5-10s)
dgraph alpha --raft="idx=4; group=1; election-tick=50"

This ensures the Raft leader stays in the segment closest to application servers, avoiding unnecessary write latency degradation from suboptimal leader placement after elections.

Default behavior is unchanged — without specifying election-tick, nodes use the previous value of 20 (2 second timeout).

Checklist

  • The PR title follows the
    Conventional Commits syntax, leading
    with fix:, feat:, chore:, ci:, etc.
  • Code compiles correctly and linting (via trunk) passes locally
  • Tests added for new functionality, or regression tests for bug fixes added as applicable
  • For public APIs, new features, etc., a PR on the
    docs repo staged and linked here.

@LakshimiRam-073 LakshimiRam-073 requested a review from a team as a code owner May 29, 2026 07:14
@matthewmcneely matthewmcneely self-requested a review May 29, 2026 16:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

1 participant