Skip to Navigation
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
- 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.
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.
Related Articles