Question about clustering

EventStoreDB
1

Hi,

I have a general question about clustering EventStoreDB. The question is simple. Apart from not loosing data if a node goes down, I wonder are there any other benefits from clustering? For instance is reading data load-balanced over the different nodes or does every request always has to go through the leader node? Is there any documentation/clarification on this? Are there any guidelines on how the client should connect to a server to get the most out of it ?

Thanks
Erik

2

The answer is a bit more complicated than the question :

The main purpose of a cluster is availability, from the point of view of

  • CAP
    • Reads are AP
    • Appends are CP
  • of hosting in a cloud environment
    • each node is typically placed in a different availability zone: a single node could result in full system failure if that zone goes down ( and it does happen )

The other aspect , in cloud environment are the limits of disk iops & throughput
( we do have people frequently depleting those) , a cluster does allow to read from any node , though the data could be stale as it needs to be replicated .
Note on staleness : appends are always written to a quorum of nodes before being acked to the client. You could just happen to read from a node that is a bit behind, the cluster as a whole is consistent .
in other words , when a node fails or is not able to reach the cluster, reading will be available.

So you can read from a follower or read-only replica using NodePreference in the connection string (Leader,Follower,Random,ReadOnlyReplica) or in code
The 2 main operations, there are more, that must happen on a Leader are Appending and Persistent Subscriptions as both require to append data .

The reads are not load balanced, doing this will make it more complex for applications to apply concurrency check , when reading from a follower or read-only replica, the code might get 4 as version number , while the leader & other node are at 5 )
When using Leader, the client will automatically connect to the leader , even if an election happened.
when using follower , it’s a kind request, you might be connected to a follower or the leader.
When Using ReadOnlyReplica , it needs to be that , except if thare are no RoR available in the cluster , most connect directly to a RoR , not using the cluster DNS or gossip seed.

For a general point of view, what we tell people is to connect to the Leader and measure the overall performance ( response time, iops, throughput) .
When those enter the orange zone, switch reading operation of the reactive side of the system ( think building up read models) to follower and measure. When that enters the orange zone… switch the reactive side of the system to a ReadOnlyReplica and measure.
Switching the needs of the write side of the system is a bit more complicated, though not that much and is rarely needed in my experience.