23.2. Setup and configuration
Neo4j HA can be set up to accommodate differing requirements for load, fault tolerance and available hardware.
In HA mode, Neo4j instances form a cluster. The instances monitor each others' availability to take account of instances joining and leaving the cluster. They elect one instance to be the master, and designate the other instances to be slaves.
For installation instructions of a High Availability cluster see Section 23.6, “High Availability setup tutorial”.
Specifying cluster members
Specify the instances that should form the cluster by supplying ha.initial_hosts
, a comma-separated list of URLs.
When each instance starts, if it can contact any of the initial hosts, then it will form a cluster with them,
otherwise it will start its own cluster.
Note that the parameter is called ha.initial_hosts
because it’s only used when instances initially join the cluster.
This means that you can extend the cluster without changing the configuration of existing instances.
Server configuration
If you are running Neo4j server, specify org.neo4j.server.database.mode=HA
in neo4j-server.properties.
HA server configuration parameters
Parameter Name | Description | Example value | Required? |
---|---|---|---|
| Whether to run as a single server or in HA mode. |
| yes |
Database configuration
HA configuration parameters should be supplied alongside general Neo4j parameters in neo4j.properties.
There are many configurable parameters, most in most cases it isn’t necessary to modify the default values.
The only parameters that need to be specified are ha.server_id
and ha.initial_hosts
.
HA database 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 |