You are currently browsing legacy 4.1 version of documentation. Click here to switch to the newest 4.2 version.

We can help you with migration to the latest RavenDB

Contact Us Now
see on GitHub

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.