Cluster: Overview


RavenDB's clustering provides redundancy and an increased availability of data that is consistent
across a fault-tolerant, High-Availability cluster.


Cluster Topology

Cluster Consensus

  • Some actions, such as creating a new database or creating an index, require a cluster consensus in order to occur.
  • The cluster nodes are kept in consensus by using Rachis, which is RavenDB's Raft Consensus Algorithm implementation for distributed systems.
  • Rachis algorithm ensures the following:
    • These actions are done only if the majority of the nodes in the cluster agreed to it !
    • Any such series of events (each called a Raft Command) will be executed in the same order on each node.

Data Consistency

  • In RavenDB, the database is replicated to multiple nodes - see Database Distribution.
  • 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).
  • Documents are kept in sync across the Database Group nodes with a master to master replication.
  • 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.

Data Availability

  • 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.

Distributed Work

  • 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.

Cluster's Health

  • 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 will use 1 core (since a server is allowed to be assigned with at least 1 core).
  • The number of assigned cores is divided evenly between all the nodes of a cluster.
  • The maximum number of cores a node can use can be limited using Studio.