Database Reference
In-Depth Information
reason.Insuchcases,anewmasteriselected,andifneedbe,broughtuptodateasmuchas
possible. If a new master is unable to be elected for whatever reason, this essentially stops
all updates to the database.
Updates are always applied on the master first, and only if this is successful are they then
appliedtotheslave.Toensureoverallconsistency,Neo4jrequiresthataslavebeuptodate
before any writes are performed, so as part of its internal communication protocol, Neo4j
will ensure that the slave has all the latest updates applied to it before performing any local
writes.
Watching an update propagate through the cluster
In order to see the pulling and pushing of updates occurring within a cluster, you can play
with the various Neo4j HA settings, and then, in combination with the Neo4j Web Admin
Console, create nodes and relationships and watch them replicate around the cluster.
Follow these steps to try this:
1
. Ensure all of your servers are up and running as described in
section 11.2.2
.
2
. Verify on each server that there are no nodes to begin with. This can be done by
going to the console tab and issuing the following Cypher query (it should return zero
rows):
start n=node(*) return n;
3
. On the master server, machine01 in this instance, use the Web Admin Console to
create two nodes and a relationship using the following Cypher statement:
CREATE (n1)-[:LOVES]->(n2);
4
. Wait until the pull interval has passed (the default value is 10 seconds—see the
ha.pull_interval
setting in the neo4j.properties file), and then verify that these
valuesarenowalsopresentontheslaveinstancesbyrunningthequeryinstep2again
on each server. You should now see two nodes listed on each server.
That's it; you've just seen Neo4j's data propagation mechanism in action!