<commit_before>How HA operates
===============

On startup a Neo4j HA instance will connect to the ZooKeeper service and register itself and ask who is master.
If some other machine is master it will start as slave and connect to the master.
If the machine starting up was the first to register or should become master according to the master election algorithm it will start as master.

When performing a write transaction on a slave each write operation will be synchronized with the master (locks will be acquired on both master and slave) and when the transaction commits it will first happen on the master.
If master commit is successful the transaction will be committed on the slave.
A slave has to be up to date with the master before performing a write operation to ensure consistency, this is built into the communication protocol between the slave and master meaning updates will happen automatically if needed.

When performing a write on the master it will execute in the same way as running in normal embedded mode.
Currently the master will not push updates to the slave, instead slaves can be configured to have a pull interval (or just let writes that happens on slaves sync up with the master).

Having all writes go through slaves has the benefit that the data will be replicated on two machines and is recommended to avoid rollbacks in case of a master failure that could potentially happen when the new master is elected.

Whenever a machine becomes unavailable the ZooKeeper service will detect that and remove it from the cluster.
If the master goes down a new master will automatically be elected.
Normally a new master is elected and started within just a few seconds and during this time no writes can take place (the write will throw an exception).
A machine that becomes available after being unavailable will automatically reconnect to the cluster.
The only time this is not true is when an old master had changes that did not get replicated to any other machine, when the old master becomes available and the new master has performed changes since elected there are two different versions of the data.
The old master will not be able to attach itself to the cluster and will require maintenance (replace the wrong version of the data with the one running in the cluster).

All this can be summarized as:

* Slaves can handle write transactions.
* Updates to slaves are eventual consistent.
* Neo4j HA is fault tolerant and (depending on ZooKeeper setup) can continue to operate from X machines down to a single machine.
* Slaves will be automatically synchronized with the master on a write operation.
* If the master fails a new master will be elected automatically.
* Machines will be reconnected automatically to the cluster whenever the issue that caused the outage (network, maintenance) is resolved.
* Transactions are atomic, consistent and durable but eventually propagated out to other slaves.
* If the master goes down any running write transaction will be rolled back and during master election no write can take place.
* Reads are highly available.<commit_msg>mild edits to HA operations text. needs further clarification<commit_after>How HA operates
===============

An HA cluster operates cooperatively, coordinating activity through Zookeeper.

On startup a Neo4j HA instance will connect to the ZooKeeper service to register itself and ask, "who is master?"
If some other machine is master, the new instance will start as slave and connect to that master.
If the machine starting up was the first to register -- or should become master according to the master election algorithm -- it will start as master.

When performing a write transaction on a slave each write operation will be synchronized with the master (locks will be acquired on both master and slave) and when the transaction commits it will first happen on the master.
If master commit is successful the transaction will be committed on the slave.
To ensure consistency, a slave has to be up to date with the master before performing a write operation; this is built into the communication protocol between the slave and master, so updates will happen automatically if needed.

When performing a write on the master it will execute in the same way as running in normal embedded mode.
Currently the master will not push updates to the slave. 
Instead, slaves can be configured to have a pull interval.
Without polling, updates will only happen on slaves whenever they sync a write with the master.

Having all writes go through slaves has the benefit that the data will be replicated on two machines.
This is recommended to avoid rollbacks in case of a master failure that could potentially happen when the new master is elected.

Whenever a machine becomes unavailable the ZooKeeper service will detect that and remove it from the cluster.
If the master goes down a new master will automatically be elected.
Normally a new master is elected and started within just a few seconds and during this time no writes can take place (the write will throw an exception).
A machine that becomes available after being unavailable will automatically reconnect to the cluster.
The only time this is not true is when an old master had changes that did not get replicated to any other machine.
If the new master is elected and performs changes before the old master recovers, there will two different versions of the data.
The old master will not be able to attach itself to the cluster and will require maintenance (replace the wrong version of the data with the one running in the cluster).

All this can be summarized as:

* Slaves can handle write transactions.
* Updates to slaves are eventual consistent.
* Neo4j HA is fault tolerant and (depending on ZooKeeper setup) can continue to operate from X machines down to a single machine.
* Slaves will be automatically synchronized with the master on a write operation.
* If the master fails a new master will be elected automatically.
* Machines will be reconnected automatically to the cluster whenever the issue that caused the outage (network, maintenance) is resolved.
* Transactions are atomic, consistent and durable but eventually propagated out to other slaves.
* If the master goes down any running write transaction will be rolled back and during master election no write can take place.
* Reads are highly available.
{'fraction_non_alphanumeric': 0.02415686274509804, 'fraction_numerical': 0.0006274509803921569, 'mean_word_length': 4.57830271216098, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '6478806', 'n_tokens_mistral': 1350, 'n_tokens_neox': 1299, 'n_words': 1048}