Cluster: Overview
RavenDB's clustering provides redundancy and an increased availability of data that is consistent
across a fault-tolerant, High-Availability cluster.
- A RavenDB Cluster consists of one or more RavenDB server instances which are called Cluster Nodes.
- Each node has a specific state and type, learn more in Cluster Topology.
- 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.
- 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.
- 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.
- 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, which can cap both the total
cores used by the cluster and the cores used by any single node.
For example, a Community license allows up to 3 cores in the cluster, with no more than 2 cores on any single node:- A single-node Community cluster can use up to 2 cores.
- In a 3-node Community cluster each node can use only 1 core, since the cluster cap is 3 and every node must be assigned at least 1 core.
- By default each node uses all of its hardware cores, up to the per-node cap. To lower a node's count (for example, to bring the cluster total within the cluster cap), use Reassign Cores in Studio.