Database Reference
In-Depth Information
there are some configurable properties (
ha.tx_push_factor
and
ha.tx_push_strategy
) that additionally push the transaction out to
n
(default 1)
slavesinan
optimistic
fashion.Byoptimistic,wemeanthatthemastermakesitsbesteffort
to ensure the transaction is propagated to the configured slaves, but if this propagation is
unsuccessful for whatever reason, the original transaction on the master will still not fail.
Otherslavescanalsocatchupbyperiodicallypollingforthelatestupdatesfromthemaster.
This is done by setting the
ha.pull_interval
property to an appropriate value for
your setup, such as
2s
(every 2 seconds). This pulling and pushing mechanism is what
is used to control the speed with which Neo4j becomes eventually consistent across the
cluster.
Note
The use of the term
optimistic
here isn't meant to be equated with the traditional database
optimistic locking
concept, where the whole transaction (including the one on the master)
would be expected to be rolled back if a conflicted DB state is detected.
Moving on to the second scenario, if a slave receives a write request, a different sequence
of events takes place, as illustrated in
figure 11.9
.
