rqlite separates permission to join without voting

Adding a replica that serves reads and adding a voter that participates in consensus are different administrative actions. rqlite 7.6.0, released on July 19, introduces the join-read-only permission. The release changelog identifies it as the new feature. The permission lets a credential join a non-voting node without granting the broader ability to admit voters.

The name refers to the node's role in rqlite's replication topology. It does not mean that a joined node receives no data changes. Read-only nodes follow the committed log and update their local SQLite database. I value this separation because read capacity can grow without making every additional copy part of the group whose votes determine progress.

A non-voting node still follows the database

The tagged read-only-node guide describes these nodes as replicas that do not contribute to quorum or vote in elections. They still receive committed entries from the leader and apply them to SQLite. The intended uses include serving more reads and placing copies nearer to clients.

That distinction limits the effect of a failed read replica on consensus. The guide says the leader continues trying to reconnect to an unreachable replica until it returns or is removed. Since the node does not vote, its absence does not prevent the voting group from committing changes through quorum.

The node is launched in this role with -raft-non-voter=true. Admission still uses the cluster's joining mechanism. The new permission changes who may request that admission, while the launch setting and join request identify the requested participation role.

Admission checks inspect the requested role

The 7.6.0 join handler first accepts a request whose credential has either join or join-read-only. It then reads the request body and determines the voter value. If that field is absent, the handler defaults it to true.

Before passing the request to the store, the handler makes another check. A request to join as a voter requires the broader join permission. A credential possessing only join-read-only therefore cannot use the initial admission check to add a voter. The second check relates the credential's authority to the actual operation described by the payload.

This two-stage logic also means the permissions are alternatives for non-voter admission. Existing broad join credentials retain the ability to admit a non-voting node. Operators do not need to add a second permission to every existing join account merely because the narrower one now exists.

The default voter value is relevant to clients constructing join requests directly. A restricted credential needs to request the non-voting role explicitly. Omitting the role does not silently turn a default voting request into a read-only join. The handler rejects the unauthorized voter operation.

A role-specific permission reduces delegated authority

An automation process adding read replicas needs enough authority to register those replicas. It need not receive authority to change the voting population. The new permission lets the credential describe that narrower responsibility instead of relying on the automation to avoid exercising a broader privilege.

The distinction belongs at the receiving service because the caller supplies the requested role. A launch script can intend to start only non-voters, but a server accepting its credential still needs to enforce that restriction. Inspecting voter before invoking the store makes the enforcement concrete.

Other membership actions remain separate. The new check does not imply permission to remove arbitrary nodes or perform unrelated administration. It introduces one narrower admission capability, with the existing store join operation behind it. Understanding the particular operation avoids reading more authority into the permission name than the handler grants.

Local reads require an explicit consistency choice

A read-only node is useful for local query execution when the request selects consistency level none. The tagged guide explains that other levels direct the work to the leader. Merely sending a query to a replica does not establish that its local SQLite copy performs the read.

The guide also recommends the freshness parameter to limit serving from a node disconnected from the leader. That connects the replication role to the client contract. Non-voting status governs consensus participation, while read consistency governs how a request obtains its result. They solve different parts of the deployment problem.

Version 7.6.0 additionally fixes freshness handling on the leader, according to its changelog. That is a separate correction from the new admission permission, but both concern making role distinctions meaningful. A leader and a non-voting replica need not apply the same local-read checks in the same way.

I consider the permission useful because it follows the actual replication role. A process provisioning read copies can hold authority to add those copies while the server continues requiring broader permission for voters. The database can then scale its readable replicas without treating every replica-provisioning credential as authority over consensus membership.