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? |
|---|---|---|---|
| integer >= 0 and has to be unique in the cluster |
| yes |
| (auto-discovered) host & port to bind when acting as master |
| no |
| whether or not to use the resource of ha.discovery.url to define the cluster |
| no |
| if ha.discovery.enabled is true, used to define the cluster | no | |
| if ha.discovery.enabled is false, a comma-separated list of other members of the cluster to join. If no members are reachable a new cluster will be created. |
| no |
| (auto-discovered) host & port to bind the cluster management communication | ||
| interval for, as slave, pulling updates from the master. Default is to not pull updates regularly, only during write transactions |
| no |
| how long a slave will wait for response from master before giving up (default 20) |
| no |
| how long a slave lock acquisition request will wait for response from master before giving up (defaults to what ha.read_timeout is, or its default if absent) |
| no |
| how long max time to gracefully await a slave/master role switch |
| no |
| max number of concurrent communication channels each slave has to its master. Increase if there’s high contention on few nodes |
| no |
| what to do with the db that is considered branched and will be replaced with a fresh copy from the master {keep_all(default),keep_last,keep_none,shutdown} |
| no |
| amount of slaves the master will push each committed transaction to |
| no |
| the strategy for selecting which slaves to push committed transactions to. "fixed" (default) will push to slaves with descending server_id order; "round_robin" will have slaves take turn receiving the transactions |
| no |
| whether this instance should only participate as slave in cluster; if enabled it will never be elected as master |
| 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.
This option requires ha.discovery.enabled be set to false.
A database instance can point to URL acting as a live list of members in a cluster, by setting ha.discovery.url to a valid and accessible URL.
If the resource pointed out by that URL exists it will take turn contacting each member in that list until it gets a response, where it will await a decision by the existing cluster members to have it join.
If the resource pointed out by the discovery URL doesn’t exist it will create it and with it a cluster having itself as initial master.
This option requires ha.discovery.enabled be set to true.