Cluster View

Cluster Stats

1. Available Cores
   Assigned: Total number of cores assigned to use for server nodes in all of the cluster
   Licensed: Total number of cores available for usage according to your license - per the whole cluster
2. Term
   Number of times that elections occurred in the cluster
3. Node State, Tag, and Address:
   A node state can be one of the following:
   • Passive - Node doesn't belong to any cluster
   • Active - Node is a fully functional member in the cluster
   • Error - Node is down or not reachable
   • Voting - Elections for a new Leader are taking place
   • Waiting - This is the state of a Watcher when the other members are in a voting process
4. Node Type
   A node type can be one of the following: (See a more detailed explanation below)
   • Member (Note: A Leader is a special member)
   • Watcher
   • Promotable
5. Cores Info
   Number of cores assigned for the node to use - out of available cores on this node's machine
6. Memory
   Memory used by the node out of total memory installed on this node's machine.
   The core-memory ratio is determined by your license type
   

Cluster Operations

1. Add New Node to Cluster
   See Add node to cluster
2. Demote
   Demote a Member to be a Watcher
3. Reassign Cores
   Reassign the number of cores to be used by the server on this node
4. Step Down
   This option is available only on the Leader node
   A new voting process will be triggered and a new Leader will be elected
5. Force Timeout
   The default configuration for the RavenDB cluster is that each node expects to get a heartbeat from the cluster leader
   (default: every 300 milliseconds).
   Clicking 'Force Timeout' will trigger actions on the node as if it did not hear from the Leader in this time period.
6. Remove Node from Cluster
   Remove the node from the cluster. Note: The server on this node is not shut down.

Reassign Cores

Learn more in Add Node to Cluster.

• Member

  • A Member is a fully functional voting member in the cluster

• Leader

  • A Leader is a Member
  • The Leader is responsible for monitoring the cluster's health, making sure that decisions making is consistent at the cluster level,
    as long as a majority of the nodes are functioning and can talk to one another. For example, the decision to add a database to a node will be either accepted by the entire cluster (eventually) or fail to register altogether.
  • The Leader maintains the database topology, which is fetched by the clients as part of their initialization.
  • Cluster-wide operations can't be done when the Leader is down.

• Watcher

  • A Watcher is a non-voting node in the cluster that is still fully managed by the cluster.
  • A Watcher can be assigned databases and work to be done.
  • Grow your RavenDB cluster by adding Watchers without suffering from large voting majorities and the latencies they can incur, as these nodes don't take part in majority calculations and are only there to watch what's going on in the cluster. So cluster decisions can be made with a small majority of nodes while the actual size of the cluster can be much higher.
  • Any number of Watchers can be added to handle the workload.

• Promotable

  • Promotable is a pre-state before becoming a Watcher or a Member.
  • Cannot make cluster decisions (i.e vote for leader, enter a new Raft command to the log).
  • Updated by the leader to the latest Raft state.

Operations in RavenDB are usually divided into cluster-wide operations and internal database operations.

Cluster-Wide Operation

• Any action/decision that is made at the cluster level and needs a Raft consensus (so that the cluster is always kept consistent).
• This decision will either be accepted by the entire cluster or completely fail to register.
  Note: An action is accepted by the entire cluster if a majority of the nodes have approved that action - if a majority of the nodes isn't available, we can't proceed.
• i.e.:
  • Creating/deleting/enabling/disabling a database
  • Creating/deleting/modifying/enabling/disabling an ongoing task
  • Creating/deleting/modifying an index

Database Operation

• Database operation can always be done on a node (even in the case of a cluster partition)
• Database operation only impacts that particular database
• Any such update is automatically replicated to all other nodes in the Database Group
• i.e.:
  • Any Read/Write operation on a database such as:
  • Create/Delete/Update a document, attachment or revision
  • Performing a query