Database Reference
In-Depth Information
len für alle drei Server öffnen, können Sie die eingebauten Gremlin-Consolen
im Web-Admin nutzen. Beachten Sie, dass das Gremlin Graph-Objekt nun
in ein HighlyAvailableGraphDatabase-Objekt gepackt wurde.
g = neo4jgraph[HighlyAvailableGraphDatabase [/.../neo4j-ent-1.7-2/data/graph.db]]
Um unsere Server zu testen, füllen wir einen neuen Graphen mit einigen
Knoten auf, die die Namen berühmter Paradoxien enthalten. An einer der
Slave-Consolen legen wir den Stammknoten mit Zenons Paradoxien fest.
gremlin> root = g.v(0)
gremlin> root.paradox = "Zeno's"
gremlin> root.save
Nun wechseln wir auf die Console des Master-Servers und lassen uns die
Werte ausgeben.
gremlin> g.V.paradox
==> Zeno's
Wechseln Sie nun auf den anderen Slave-Server und fügen Russells Antino-
mie hinzu, zeigt ein kurzer Blick auf unsere Liste, dass beide Knoten auf dem
zweiten Server vorhanden sind, obwohl wir hier nur einen eingegeben haben.
gremlin> g.addVertex(["paradox" : "Russell's"])
gremlin> g.V.paradox
==> Zeno's
==> Russell's
Wenn die Änderungen noch auf einen der Slave-Server durchgereicht wur-
den, können Sie noch einmal zur High-Availability-Seite in der Server-Info
wechseln. Sehen Sie sich alle Instanzen von
lastCommittedTransactionId
an.
Wenn diese Werte gleich sind, sind die Systemdaten konsistent. Je kleiner der
Wert, desto älter die Version der Daten auf diesem Server.
Wahl des Masters
Wenn Sie den Master-Server herunterfahren und die Server-Infos für die rest-
lichen Server aktualisieren, werden Sie sehen, dass ein anderer Server als
Master gewählt wurde. Wenn Sie den Server wieder starten, wird er wieder
in den Cluster eingefügt, aber nun bleibt der alte Master ein Slave (bis ein
weiterer Server ausfällt).
Hochverfügbarkeit erlaubt es Systemen mit sehr hohen Leseaktivitäten, ei-
nen Graphen über mehrere Server zu replizieren und damit die Last zu ver-
