A group of nodes in the cluster that contains the same database is called a Database Group.
(The number of nodes in the database group is set by the replication factor supplied when creating the database).
Any document related change such as a CRUD operation doesn't go through Raft,
instead, it is automatically replicated to the other database instances to in order to keep the data up-to-date.
Due to the consistency of the data, even if the majority of the cluster is down, as long as a single node is available, we can still process Reads and Writes.
Read requests can be spread among the cluster's nodes for better performance.
Whenever there's a Work Task for a Database Group to do (e.g. a Backup task),
the cluster will decide which node will actually be responsible for it.
These tasks are operational even if the node to which the client is connected to is down, as this nodes' tasks are re-assigned to other available nodes in the Database Group.
The cluster's health is monitored by the Cluster Observer which checks upon each node in the cluster.
The node state is recorded in the relevant database groups so that the cluster can maintain the database replication factor and re-distribute its work tasks if needed.
CPU Core Distribution
A cluster is limited in the maximum number of CPU cores that can be used by all of its nodes
at a given time.
This limit is determined by the cluster's RavenDB license. For example, a Community licensed
cluster can have up to 3 cores. This means that when there is just one node in the cluster, it
can use 1-3 cores. If there are 3 nodes, each of them can only use 1 core (a RavenDB server
cannot be assigned less than 1 core).
The number of assigned cores is divided evenly between all the nodes of a cluster.
A node can be limited to a maximum number of cores it can use. This can be configured
in the Studio.