rqlite's Raft port separates server identity from address

A server address is a convenient identity until the address changes or a replacement process occupies it. Consensus membership needs to distinguish the participant from the location used to contact it. Hashicorp Raft 1.0 introduces that distinction, and adopting the library therefore involves more than compiling against renamed methods.

In his 9 April 2018 announcement, Philip O'Toole says rqlite has already been ported to Raft 1.0. He identifies the port as a key change for the upcoming rqlite 5.0 release. This is an announcement about completed porting work and a planned release, not an announcement that 5.0 is available.

I like rqlite's use of an established consensus library alongside SQLite. That division keeps the project focused, but an upstream protocol change still becomes an operational concern for the database. The application has to choose how its nodes move between compatible implementations.

Identity becomes separate membership information

The Raft 1.0 README describes breaking API changes associated with server identities. It also introduces protocol versioning and warns that interoperability with older servers requires special steps. The new library can represent information that the older membership model could not carry.

The versioned configuration commentary explains the old model directly. In the transitional protocol, server IDs remain equal to network addresses because the legacy membership log entry cannot transmit a separate ID. Newer configuration entries can carry the full identity information.

This is a data-model change inside the replicated log. Even if two application builds expose the same HTTP endpoints, they may disagree about which membership records they can understand or generate. Client compatibility alone cannot establish cluster compatibility.

Separating identity from address also changes the membership APIs. The library introduces operations such as AddVoter, AddNonvoter and RemoveServer. A remove operation takes the identity of the member being removed, rather than treating its current network location as the only possible identifier.

For an existing member, the configuration comments describe leaving and re-entering the cluster to acquire a new ID. The old address initially remains the member's identity. Changing a local configuration field cannot by itself rewrite the identity recognized by the rest of the cluster.

Understanding and speaking a protocol are different

The library distinguishes protocol versions a server understands from the version it uses when communicating. That distinction lets a transitional build understand a newer configuration format while still generating older membership entries for compatibility.

Protocol version 1 can interoperate with unversioned servers. It uses the old membership entry representation and retains address-based IDs. Protocol version 2 begins generating the new configuration entries while retaining enough support to participate in the staged migration.

Version 3 supports the identity-based APIs fully and no longer supports the old peer APIs. The intermediate version is necessary because existing nodes need to learn the identity information before the cluster relies on it. Skipping that step can leave nodes unable to recognize their own voting status.

These are library protocol versions, not rqlite release numbers. Raft 1.0 supports several protocol stages, and a database application chooses which stage a particular build uses. Equating the package version with the wire protocol would hide the actual compatibility decision.

The same comments say there is no automatic version negotiation. Compatible settings must be configured deliberately. An operator cannot assume that starting a newer executable causes every peer to converge on a mutually supported format.

Snapshots also preserve membership

Raft's configuration source versions snapshots separately from the communication protocol. The new snapshot format contains a full configuration and its associated log index, including server identities and voting modes. It also retains legacy peer information to ease upgrades.

This matters because a snapshot does more than save application records. It also preserves information needed to interpret the consensus state after log compaction or restoration. A database backup format and a Raft snapshot therefore answer different questions.

The README explains that a state-machine snapshot must restore the same state as replaying the preceding log. Membership information has to remain coherent with that restored state. Adding independent IDs affects both live configuration changes and the durable representation used during recovery.

Non-voting servers are another capability named by the library release. Their existence makes voting status explicit instead of assuming every replicated participant has the same role. Whether and how a database exposes that capability is an application-level decision, so the library's feature list should not be presented as a list of features already released by rqlite.

The announcement does not specify a deployment procedure

O'Toole's short post confirms the port and its intended place in 5.0. It does not publish a complete upgrade procedure for an existing rqlite cluster. The library documentation explains why such a procedure needs care, but it cannot substitute for the database's eventual release instructions.

That leaves a useful distinction between understanding the work and prescribing an upgrade. The known change is that rqlite's consensus dependency has been ported to a version with explicit identity and protocol concepts. The safe sequence for a particular deployed database remains something its release needs to define.

For me, this is the consequential part of the announcement. A small database can delegate consensus implementation while still owning the compatibility policy presented to its operators. Raft 1.0 supplies the mechanisms for staged interoperability, and the planned rqlite release must connect those mechanisms to the identities and persistent state of its own nodes.