rqlite exposes the candidate election timeout
rqlite 4.4.0 adds a command-line setting for the Raft election timeout. Its meaning differs from the existing follower heartbeat timeout, and the underlying library validates their relationship.
Failure detection and retrying an unsuccessful election are different intervals in rqlite's Raft implementation. The existing heartbeat timeout governs a follower waiting for a leader. The election timeout governs a candidate waiting without establishing one. rqlite 4.4.0, released on 4 January, exposes the latter as a command-line setting, giving operators control over a previously less accessible part of leadership changes.
That distinction matters because a setting named election timeout can be mistaken for the entire time required to recover leadership. The implementation has several timers with separate responsibilities. Adjusting one candidate interval does not directly define how quickly a follower decides the leader is absent, nor does it promise when a new leader will obtain the required agreement.
I value rqlite's proportionality. SQLite supplies relational storage, and Raft supplies the agreement needed to replicate it. A small deployment should still be able to see the relevant distributed-system settings. Exposing this interval makes the consensus behavior more explicit without requiring the operator to replace the database architecture.
The option reaches Raft configuration
The 4.4.0 daemon source declares -raft-election-timeout with a default of 1s. It separately declares -raft-timeout, also defaulting to 1s, as the Raft heartbeat timeout. The flag names are not interchangeable, even though their default values match.
An illustrative invocation can change the candidate interval while leaving the follower interval at its default.
rqlited -raft-election-timeout 2s ./node-data
This value is an example of the syntax, not a recommendation for every deployment. The daemon parses both options using Go's duration parser and reports a fatal startup error when either supplied duration cannot be parsed. It then assigns the values to the store's heartbeat and election fields.
The store implementation passes nonzero values into the corresponding fields of the Raft configuration. Its status data includes both heartbeat_timeout and election_timeout as duration strings. The distinction therefore exists in the daemon flags, the store and the underlying consensus configuration. It is not merely a renamed version of the older option.
What each timeout measures
The Raft configuration vendored in this release defines the terms directly. HeartbeatTimeout specifies time spent in follower state without a leader before attempting an election. ElectionTimeout specifies time spent in candidate state without a leader before another election attempt. These definitions are the relevant ones for the rqlite binary being released.
A node can consequently pass through more than one waiting phase during a leadership interruption. Detecting the lack of a leader begins the election process. Being a candidate does not itself establish leadership. If that candidacy fails to produce a leader, the candidate timeout controls another attempt. A single flag cannot summarize every path through those states.
The same configuration defines a leader lease timeout for stepping down after losing contact with a quorum. It also defines a commit timeout related to heartbeats when there has been no apply operation. Their presence explains why changing the election timeout should be described narrowly. The library distributes responsibilities across several named conditions.
Validation constrains the settings
The vendored library requires the election timeout to be at least as large as the heartbeat timeout. It rejects election and heartbeat intervals below five milliseconds. These checks establish accepted relationships and lower bounds. They do not establish an appropriate production setting for a particular network or machine.
For example, increasing the follower interval while leaving the candidate interval below it violates the library's configuration rule. Setting the new flag is therefore part of a configuration with related values, rather than an independent request that every combination can satisfy. The two one-second defaults satisfy the ordering constraint by equality.
A longer candidate interval gives an unsuccessful election attempt a different retry schedule. A shorter interval requests another attempt sooner, subject to validation and the rest of the protocol. Neither adjustment removes the requirement for nodes to communicate. A deployment that cannot assemble the required agreement cannot turn a timeout value into successful leadership.
Relational storage still depends on consensus
The release-pinned README describes rqlite's statement-based replication and its durable Raft log. SQLite executes the replicated statements, and the log remains authoritative even when the local SQLite database is in memory. Leader election belongs to that replication mechanism, rather than to a SQLite query execution setting.
I find that separation useful when judging the new option. The database can retain a compact operational model while exposing the timing rules that govern its replicated write authority. In 4.4.0, the candidate election interval can be configured explicitly and observed separately from the follower heartbeat interval, using the names and constraints of the Raft implementation actually included in the release.