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.