see on GitHub

Consensus Operations



Operations that require Consensus

Since getting a consensus is an expensive operation, it is limited to the following operations only:

  • Creating / Deleting a database
  • Adding / Removing node to / from a Database Group
  • Changing database settings (e.g. revisions configuraton , conflict resolving)
  • Creating / Deleting Indexes (static and auto indexes)
  • Configuring the Ongoing Tasks

See Implementation Details below.

Operations that do not require Consensus

  • It is important to understand that any document related operation does not require a consensus.
    Any document CRUD operation or performing a query on an existing index is executed against a specific node,
    even in the case of a cluster partition.

  • Since RavenDB keeps documents synchronized by Replication, any such operation is automatically replicated to all other nodes in the Database Group, so documents are always available for Read, Write and Query even if there is no majority of nodes in the cluster.

Raft Commands Implementation Details

Raft Index

  • Every Raft command is assigned a Raft Index, which corresponds to the commands sequence execution order.
    For example, an operation with the index 7 is executed only after all operations with a smaller index have been executed.

  • If needed, a client with Valid User privileges can wait for a certain Raft command index to be executed on a specific cluster node.
    This is done by issuing the following REST API call:

Action Method URL
Wait fro Raft Command GET /rachis/waitfor?index=index
  • The request will return after the corresponding Raft command was successfully applied -or-
    a timeout is returned after Cluster.OperationTimeoutInSec has passed (default: 15 seconds).

Raft Command Events Sequence

  • When a Raft command is sent, the following sequence of events occurs:

    1. The client sends the command to a cluster node.
    2. If the receiving node is not the Leader, it redirects the command to the Leader.
    3. The Leader appends the command to its log and propagates the command to all other nodes.
    4. If the Leader receives an acknowledgment from the majority of nodes, the command is actually executed.
    5. If the command is executed at the Leader node, it is committed to the Leader Log, and notification is sent to other nodes.
      Once the other nodes receive the notification, they execute the command as well.
    6. If a Non-Leader node executes the command, it is added to the node log as well.
    7. The client receives the Raft Index of the command issued, so it can be waited upon.