Replication

Single-leader (or master-slave) replication is supported. However, the current implementation is trivial and there are still improvements to be made to improve consistency and fault-tolerance.

Creating a read-replica

In order to initialize a node as a read-replica, a node must be started with the master_ip and master_port arguments set. See the server page for more about spinning up nodes. When these arguments are set, the client will send the REPLICA command to the server, which registers the current node as a read-replica with the master node and connects the master node to the current read-replica node's primary port.

If the master_ip and master_port are invalid when initializing a read-replica node, the startup will fail and terminate.

Command forwarding

Once a node is registered as a read-replica with a master node, the master node will forward all read commands to the read-replica to keep them in sync.

Reconnecting

If the master becomes disconnected from the read-replica, it will attempt to reconnect to the read-replica before forwarding a command. This reconnection happens once per command forwarded.

Caveats

⚠️ Deregistering lost read-replicas that go offline for too long is not currently supported, and the master node will still continue to attempt to forward commands to offline read-replicas (this doesn't block the master node though, since a reconnection is attempted only once per command). If the read-replica comes back online, it will be out of sync with the master and repairing a node isn't yet supported.

⚠️ A caveat with the current implementation is that all read-replica nodes must be spun up before the master-node starts processing write operations. This is because currently, the server does not sync its current state with a read-replica when the read-replica is initialized and only forwards commands to the read-replica after the read-replica has been registered and connected with the server. More robust read-replica synchronization is yet to be implemented.