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.

    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 articlesRelated Articles

    Cluster in the Studio

    Home / Docs / Server / Clustering / Overview