Database Reference
In-Depth Information
Bei der Replikation von Daten gibt es ganz eigene Aspekte, die bei einer einfa-
chen Datenbank nicht auftauchen. Beim Mongo-Setup besteht ein Problem
darin, zu entscheiden, welcher Server zum Master wird, wenn der Master-
Knoten ausfällt. Mongo löst das Problem, indem es bei jedem
mongod
nach-
fragt und den mit den aktuellsten Daten zum neuen Master befördert. Im
Moment sollten noch zwei
mongod
-Instanzen laufen. Gehen Sie nun hin und
fahren Sie den aktuellen Master herunter. Denken Sie daran, dass bisher in
diesem Fall einfach ein anderer zum neuen Master auserkoren wurde. Doch
diesmal passiert etwas anderes. Die Ausgabe des letzten verbliebenen Servers
sieht etwa so aus:
[ReplSetHealthPollTask] replSet info localhost:27012 is now down (or...
[rs Manager] replSet can't see a majority, will not try to elect self
Das hat mit der Mongo-Philosophie der Server-Setups zu tun und ist der
Grund, warum Sie immer eine ungerade Zahl von Servern verwenden sollten
(drei, fünf und so weiter).
Starten Sie nun wieder die anderen Server und sehen Sie sich die Logs an.
Wenn die Knoten wieder laufen, wechseln Sie in den Wiederherstellungsmo-
dus und versuchen, Ihre Daten mit dem neuen Master-Knoten abzugleichen.
„Moment mal!?“ (hören wir Sie sagen). „Was passiert, wenn der eigentliche
Master Daten besitzt, die noch nicht propagiert wurden?“ Diese Operationen
werden verworfen. Eine Schreiboperation in einem Mongo Replica-Set wird
nicht als erfolgreich erachtet, bis die meisten Knoten eine Kopie der Daten
besitzen.
Das Problem mit der geraden Knotenzahl
Das Konzept der Replikation ist einfach zu verstehen: Sie schreiben etwas an
einen MongoDB-Server und diese Daten werden innerhalb des Replika-Sets
auf die anderen kopiert. Ist ein Server nicht verfügbar, übernimmt einer der
anderen und verarbeitet die Requests. Doch es muss nicht an einem Absturz
liegen, dass ein Server nicht verfügbar ist. Manchmal ist die Netzwerkver-
bindung zwischen den Knoten unterbrochen. In diesem Fall schreibt Mongo
vor, dass
eine Majorität von Knoten, die immer noch kommunizieren können,
das Netzwerk bilden
.
MongoDB erwartet eine ungerade Anzahl von Knoten im Replika-Set. Be-
trachten wir zum Beispiel ein aus fünf Knoten bestehendes Netzwerk. Wenn
ein Verbindungsausfall es in ein 3-Knoten- und ein 2-Knoten-Fragment teilt,
hat das größere Fragment eindeutig die Majorität, es kann einen Master wäh-
len und weiterhin Requests verarbeiten. Ohne Mehrheit ist man nicht be-
schlussfähig.
