The cooperative operation of a Neo4J HA cluster, the coordination behavior is done through zookeeper.
When a Neo4j HA entity is started it will go to the coordinator service (zookeeper) to register itself and ask "Who is the master?". If a machine is the master, the new entity will start as a slave and connect to the master. If the machine is powered on as the first to register or should be the host via the host selection algorithm , it will be powered on as the host.
When executing a write transaction from a slave, each write operation will be synchronized with the master (master and slave will be locked). First exists on the host when a transaction commits. When the master transaction is successfully committed, the transaction on the slave is also committed. To ensure consistency, slave and master synchronization must be up to date before performing a write operation. This is the protocol that establishes the communication between the master and the slave, so updates will happen automatically if needed.
Database entities can be set as slaves only by setting the configuration file including the ha.slave_coordinator_update_mode=none configuration parameter . This entity, although it will not be possible to become the master at the time of system failover election, the slave behaves like all other slaves, including the ability to write permanently to the master.
When a write operation is performed from the host, it will be performed as in normal embedded mode. At this time, the master will not push the update message to the slave. Instead, slaves can configure a time interval for pulling messages. Without elections, update operations will only occur on the slave, and a write will be synchronized to the master at any time.
The benefit of having all writes go through the slave is that the data will be replicated on both machines. This is recommended to avoid possible rollback failures when a new host is selected.
When a neo4j database service becomes unavailable, the coordinator will detect it and remove it from the cluster. When a host goes down, a new host will be automatically selected. Typically, a new host is selected and started within a few seconds, during which time no writes will be performed (writes will throw exceptions). When a machine recovers from a failure, it will be automatically reconnected to the cluster. The only uncertainty is when the old host changes without being backed up by any other machine. If a new host is selected and changes are performed before the old host is restored, there will be two different versions of the data. The old host will remove the branch database and download a full version of the data from the new host.
Ø All of these can be summarized as follows:
Ø The slave can process write transactions.
Ø The update relative to the slave will eventually be consistent.
Ø Neo4j HA is a fault tolerant and can continue to execute from x machines to a single machine (based on zookeeper settings).
Ø The slave will automatically synchronize to the master on write operations.
Ø When the host fails, a new host will be automatically selected.
Ø The current machine will be automatically reconnected to the cluster when any errors (networking, maintenance) that cause outages are resolved.
Ø The atomicity, durability and consistency of the transaction will eventually be broadcast to other slaves.
Ø When the host fails, all running write transactions will be rolled back, and no write operations can be performed during host election.
Ø Read operations are highly available.