Neo4j HA can be set up to accommodate differing requirements for load, fault tolerance and available hardware.
Within a cluster, Neo4j HA uses its own Paxos implementation for all cluster membership related tasks, from instances joining/leaving a cluster to master election and availability information propagation.
Read operations through the GraphDatabaseService API will always work, whereas write operations requires an available master.
For reaching quorum among the members in the cluster the number of members should be odd.
For installation instructions of a High Availability cluster see Section 26.6, “High Availability setup tutorial”.
Note that while the HA version of Neo4j supports the same API as the single instance embedded version, it does have additional configuration parameters. Although there are many parameters, most of them have defaults that should work in most cases.
HA configuration parameters
| Parameter Name | Description | Example value | Required? |
|---|---|---|---|
| Id for a cluster instance. Must be unique within the cluster. |
| yes |
| A comma-separated list of other members of the cluster to join. |
| yes |
| Host & port to bind the cluster management communication. |
| no |
| Whether to allow this instance to create a cluster if unable to join. |
| no |
| Default timeout used for clustering timeouts. Override specific timeout settings with proper values if necessary. This value is the default value for settings ha.heartbeat_interval, ha.paxos_timeout and ha.learn_timeout. |
| no |
| How often heartbeat messages should be sent. Defaults to ha.default_timeout. |
| no |
| Timeout for heartbeats between cluster members. Should be at least twice that of ha.heartbeat_interval. |
| no |
| Timeout for broadcasting values in cluster. Must consider end-to-end duration of Paxos algorithm. This value is the default value for settings ha.join_timeout and ha.leave_timeout. |
| no |
| Timeout for joining a cluster. Defaults to ha.broadcast_timeout. |
| no |
| Timeout for waiting for configuration from an existing cluster member during cluster join. |
| no |
| Timeout for waiting for cluster leave to finish. Defaults to ha.broadcast_timeout. |
| no |
| Default timeout for all Paxos timeouts. Defaults to ha.default_timeout. This value is the default value for settings ha.phase1_timeout, ha.phase2_timeout and ha.election_timeout. |
| no |
| Timeout for Paxos phase 1. Defaults to ha.paxos_timeout. |
| no |
| Timeout for Paxos phase 2. Defaults to ha.paxos_timeout. |
| no |
| Timeout for learning values. Defaults to ha.default_timeout. |
| no |
| Timeout for waiting for other members to finish a role election. Defaults to ha.paxos_timeout. |
| no |
| How long a slave will wait for response from master before giving up. |
| no |
| Timeout for waiting for instance to become master or slave. |
| no |
| Timeout for taking remote (write) locks on slaves. Defaults to ha.read_timeout. |
| no |
| Maximum number of connections a slave can have to the master. |
| no |
| Hostname and port to bind the HA server. |
| no |
| Whether this instance should only participate as slave in cluster. If set to true, it will never be elected as master. |
| no |
| Policy for how to handle branched data. |
| no |
| Max size of the data chunks that flows between master and slaves in HA. Bigger size may increase throughput, but may be more sensitive to variations in bandwidth, whereas lower size increases tolerance for bandwidth variations. |
| no |
| Interval of pulling updates from master. |
| no |
| The amount of slaves the master will ask to replicate a committed transaction. |
| no |
| Push strategy of a transaction to a slave during commit. |
| no |
![[Note]](images/icons/admon/note.png){kind=icon} | Note |
|---|---|
Note that the |
There are currently multiple ways of telling your database instance which cluster to create/join, different ways for different occasions.
A database instance can join a cluster by supplying ha.initial_hosts a comma-separated list of URLs to at least one other cluster member of the cluster to join.
It’s called initial hosts since it’s only for joining the cluster. After an instance joins it gets aware of all the members of the cluster.
It will take turn contacting each one in the list until it gets a response, where it will await a decision by the existing cluster members to have it join.
If it cannot contact any of the members in the URL list it will create a new cluster with itself as master.