By default (or by explicitly setting the
ReadBalanceBehavior conventions to
None), the cluster designates
a primary node that all read and write client requests are
In case of a failure, the primary node is automatically replaced by another.
convention can be used to change this behavior for read requests, and spread
them among all cluster nodes. write requests, however, would still always
be sent to the primary node.
LoadBalanceBehavior convention set to
the default behavior can change for write requests as well: sessions
can use a
tag while sending requests, and all the sessions that use
the same tag will share the same primary node in the database topology.
To load-balance requests, you can use different tags.
Consider, for example, a database with three nodes:
If you are using a per-user context, sessions sending their requests with
users/1-A tag may be given node B as their primary node (for
both reads and writes), while sessions that send requests with the
users/2-A tag will be given node C as primary.
Besides allowing the session to select the primary node, RavenDB's behavior
is unchanged: replication between database nodes operates normally, and
write requests sent to one node are replicated to all other nodes.
Spreading requests between cluster nodes is useful when there is some degree
of separation in your system, and a specific set of sessions typically handles
a specific set of documents.
A common example would be setting the context to the current user or tenant,
allowing the read and write load to spread across cluster nodes on a fair basis.
Node failure is handled normally, and even the failure of a primary node to
handle a particular
tag will not be visible to your code: failover to another
database node will happen automatically and transparently.