Neo4j Enterprise Cluster Basics

Neo4j Enterprise enables a high availability cluster using the PAXOSprotocol for cluster communication prior to 3.x and the RAFT protocol with the core-edge clustering model is now available in the current milestone releases. If you’re interested into diving deeper into specifications and the implementation of the new RAFT protocol, I suggest you checkout Jim Webber’s great overview in his keynote from GraphConnect SF 2015. One very useful feature coming in 3.x is the ability to read your own writes. Meaning you can require that the transaction with write you made to core is available on the edge server handling the read request before it returns your request.

So while that is coming in 3.x, what is the current landscape in 2.x?

Neo4j Enterprise Write Operations

When operating a Neo4j Enterprise cluster, there will always be one master instance and some number of slaves. Neo4j is capable of handling write requests on all instances, but that requires the slave to proxy the request to the master so it is best to separate reads and writes to ensure the master is the only Neo4j instance handling write requests.
Writes to the Neo4j master instance will be optimistically pushed to zero or more slaves as configured. This means the master will try pushing the successfully written transaction to the specified number of slaves prior to the write request completion. If the replication ends up failing for any reason, the transaction on the master will still remain successful although it will be different from the typical normal replication factor. The Neo4j slave instances will continue to pull for their updates at the configured interval so the writes will still eventually replicate and be available for read requests.

Neo4j Enterprise Master Re-Election

Whenever a Neo4j Enterprise graph database instance becomes unavailable (as a result of network outages 

Read More......