Replication
Introduction
Replication allows two or more Kanidm servers to exchange their databases and keep their content synchronised. This is critical to allow multiple servers to act in failover groups for highly available infrastructure.
Kanidm replication is eventually consistent. This means that there are no elections or quorums required between nodes - all nodes can accept writes and distribute them to all other nodes. This is important for security and performance.
Because replication is eventually consistent, this means that there can be small delays between different servers receiving a change. This may result in some users noticing discrepancies that are quickly resolved.
To minimise this, when you operate replication in a highly available deployment you should use a load balancer which uses sticky sessions so that users are redirected to the same server unless a failover event occurs. Another option is an “active-passive” configuration where your load balancer targets a single node. Since replication is eventually consistent, there is no need for a manual failover or failback procedure in Kanidm.
In this chapter we will cover the details of planning, deploying and maintaining replication between Kanidm servers.
Vocabulary
Replication requires us to use introduce specific words so that we can describe the replication environment.
Change
An update made in the database.
Node
A server that is participating in replication.
Pull
The act of requesting data from a remote server.
Push
The act of supplying data to a remote server.
Node Configuration
A descriptor that allows a node to pull from another node.
Converge
To approach the same database state.
Topology
The collection of servers that are joined in replication and converge on the same database content. The topology is defined by the set of node configurations.
Replication
The act of exchanging data from one node to another.
Supplier
The node that is supplying data to another node.
Consumer
The node that is receiving content from a supplier.
Refresh
Deleting all of a consumer’s database content, and replacing it with the content of a supplier.
Incremental Replication
When a supplier provides a “differential” between the state of the consumer and the supplier for the consumer to apply, coverging toward the same database state.
Conflict
If a consumer can not validate a change that a supplier provided, then the entry may move to a conflict state. All nodes will converge to the same conflict state over time.
Tombstone
A marker entry that displays an entry has been deleted. This allow all servers to converge and delete the data.