rqlite exposes the Raft leader lease timeout

A leader that can no longer contact enough voting members needs a rule for when to stop acting as leader. rqlite 5.6.0 exposes the Raft leader lease timeout as a startup setting. The November 17 announcement describes additional control over the Raft subsystem, and the release also updates its Raft dependency to 1.2.0. The setting makes an existing consensus timing decision available to the operator.

This timeout is about recent contact with a voting quorum. It is separate from how long an individual SQL request may execute and from a local read's freshness threshold. The names all concern time, but they inspect different state and lead to different actions. Here the consequence is a leader stepping down when its contact evidence is insufficient.

I value rqlite's limited collection of operational controls. Exposing one more is useful when its meaning is precise enough to understand against the system's actual behavior. The lease setting has that meaning in the underlying Raft implementation, including constraints on how it can relate to other timeouts.

Zero selects the dependency's default

The server entry point at this tag names the option -raft-leader-lease-timeout and defaults it to 0s. Its help text explains that zero uses the Raft default. The value is parsed as a duration before being assigned to the store's lease-timeout field.

The store configuration code starts with raft.DefaultConfig() and overrides the lease timeout only for a nonzero value. Zero therefore does not mean a lease of zero duration. It means the application leaves this particular dependency setting unchanged.

An illustrative launch can make that default-selection policy explicit. It does not recommend a different timing for an unspecified deployment.

rqlited -raft-leader-lease-timeout 0s ~/node-1

This convention is useful to distinguish from disabling the mechanism. The leader lease check remains part of Raft's behavior under its selected default. A deployment setting that chooses the default should not be described as permitting the leader to continue indefinitely without quorum contact.

The check counts voting members

The Raft 1.2.0 leader implementation examines members whose suffrage is Voter. It counts the local leader as contacted and compares each other voter's last contact with the lease duration. Recent enough contacts count toward the total. If that total is below the quorum size, the node changes to follower state.

The quorum calculation uses integer division of the number of voters by two, with one added to the result. Non-voting replicas do not enlarge that electorate or contribute contact evidence to this check. A cluster can therefore have many read-serving replicas without those replicas substituting for missing voting members in the leader lease calculation.

That detail connects the setting to rqlite's topology. Contact with an arbitrary reachable node is not sufficient evidence for this purpose. The implementation asks whether enough of the configured voting membership has been contacted recently. The action follows the count and the duration together.

The timeout has validation constraints

The Raft configuration code in the same version requires a leader lease timeout of at least five milliseconds. It also rejects a lease timeout greater than the heartbeat timeout. Those constraints prevent treating this newly exposed flag as an independent duration with no relationship to the rest of the configuration.

The heartbeat timeout controls another part of Raft's timing, so an operator changing related settings needs a valid combination. A longer lease does not come with permission to ignore the dependency's validation. Conversely, using zero in the rqlite option delegates the choice to the default configuration instead of passing zero through as a proposed lease value.

Lengthening the permitted contact interval makes the leader tolerate older contact evidence before this check forces it to step down. Shortening it makes the check reject that evidence sooner. Those are consequences of the comparison in the code. The release does not establish one optimal value for every network or workload.

I prefer explaining the setting through that comparison instead of treating it as a generic availability adjustment. It governs a particular leader-state transition based on voting-member contact. It does not change which SQL statements are valid or create a new read-consistency contract.

The dependency update is also explicit in the 5.6.0 changelog. That identifies which Raft implementation gives the flag its behavior in this release. The practical result is an operator-controlled lease duration with documented default selection and validation, backed by a check that steps down when recent voting-quorum contact is missing.