Database Reference
In-Depth Information
Fault tolerance
Neo4j provides the custom implementation of multi-paxos paradigm at
ht-
tp://en.wikipedia.org/wiki/Paxos_%28computer_science%29#Multi-Paxos
, which provides
the following features:
• Cluster management keeps a track of the leaving or joining nodes. It checks the
heartbeat of the other participating nodes in a cluster and keeps a track of the last
sync and its availability.
• Message broadcasting and replication.
• Electing and choosing master nodes.
• Assisting Neo4j HA database in transaction propagation and data replication.
Note
You can also read more about Paxos from
http://research.microsoft.com/en-us/um/people/
Although reads can be served even with a single node, when it comes to writes, it is essen-
tial to have a Quorum of nodes available in a cluster.
Whenever a Neo4j database instance becomes unavailable, due to any reason such as hard-
ware or network failure, the other database instances in the cluster will detect that and mark
it as temporarily failed.
Once the temporarily failed instance is available and ready to serve user requests, it is auto-
matically synced with the other nodes in the cluster.
If the master goes down, then another (best-suited) member will be elected and have its
role switched from slave to master after a quorum has been reached within the cluster.
Writes are blocked during the election process of the master node.
For all those cases where Quorum is not available and we still want to elect the master,
Neo4j provides arbiter nodes that can be deployed to achieve the Quorum. Arbiter nodes do
not contain the data and neither serve the read or write requests. They are used only in the
election of the master node with the single purpose of breaking ties.
Arbiter instances are configured in the same way as Neo4j HA members are configured in
the
neo4j.properties
file under
conf/
and the following command is used to start
an arbiter instance:
