Database Reference
In-Depth Information
ha.server
_
id=2
ha.coordinators=localhost:2181,localhost:2182,localhost:2183
ha.server=localhost:6002
ha.pull
_
interval=1
Wir setzen
pull
_
interval
auf 1, was bedeutet, dass jeder Slave einmal pro Se-
kunden den Master auf Updates überprüft. Üblicherweise ist der Wert nicht
so klein, aber auf diese Weise können wir die Updates für die Beispieldaten
sehen, die wir gleich einfügen.
Nachdem wir unsere Neo4j HA-Server konfiguriert haben, ist es an der Zeit,
sie zu starten. Genau wie die Koordinator-Server starten wir auch die Neo4j-
Server in ihren jeweiligen Installationsverzeichnissen.
bin/neo4j start
Sie können sich die Ausgaben des Server ansehen, indem Sie sich den Log
per tail ausgeben lassen.
tail -f data/log/console.log
Jeder Server hängt sich an seinen konfigurierten Koordinator an.
Den Cluster-Status prüfen
Der zuerst gestartete Koordinator wird zum Master-Server - wahrscheinlich
Server 1. Sie können das überprüfen, indem Sie den Web-Admin der ange-
schlossenen Neo4j-Instanz öffnen (wir haben eben Server 1 auf Port 7471
gesetzt). Klicken Sie oben den Server Info-Link an und dann im seitlichen
Menü auf High Availability.
6
Die Properties unter High Availability liefern Informationen zu diesem Clus-
ter. Wenn der Server der Master-Server ist, ist die Property wahr. Wenn nicht,
können Sie unter InstancesInCluster nachsehen, wer zum Master gewählt
wurde. Hier finden Sie alle angeschlossenen Server samt Rechner-ID, wel-
cher der Master ist und weitere Informationen.
Replikation prüfen
Da unser Cluster nun funktioniert, können wir überprüfen, ob die Server
korrekt replizieren. Wenn alles nach Plan läuft, sollten alle Schreiboperatio-
nenaneinenSlaveirgendwannaufdenMaster-Knotenrepliziertwerdenund
schlussendlich auch an die anderen Slave-Server. Wenn Sie die Web-Conso-
