MongoDb Vorbereitung für geschuppte Cluster

Question

Wir richten derzeit unsere mongodb-Umgebung für die Produktion ein. Im Moment haben wir nur einen dedizierten mongodb Datenbankserver. Wir werden dies in naher Zukunft mit einem zweiten Server erweitern und habe dem Management bereits mitgeteilt, dass wir für die ideale Situation auch einen dritten Server bekommen sollten.

Da ich bereits weiß, dass wir in naher Zukunft Sharding und Replikation verwenden, möchte ich darauf vorbereitet sein.

Die Idee, die ich jetzt habe, ist jetzt mit der Entwicklungskonfiguration zu beginnen (wie mongo's Dokumentation es nennt).

Jedes Mal, wenn unser zweiter Server möchte ich erweitern diese Einstellung auf eine Konfiguration mit 2 Konfigurationsservern en 2 Scherben (Replikatsätzen) verfügbar kommt.

Und natürlich, wenn unser dritter Server verfügbar ist, haben Sie die voll funktionsfähige Shard Cluster Konfiguration.

Beim Lesen von Mongos Dokumentation wurde ich durch den Hinweis ausgelöst, dass de Development setup nicht in der Produktion verwendet werden sollte.

MongoDb Development Configuration

Wenn man bedenkt, dass wir bald weitere Server hinzufügen, wäre es eine schlechte Idee sein, um bereits die Development Configuration konfiguriert bereits so können wir leicht den zweiten Server zum Cluster hinzufügen, wenn es verfügbar kommt?

Answer 1

Nachdem ich das 'Development Sharded Setup' eingerichtet habe, habe ich mein Anwsser gefunden. Natürlich teile ich es gerne für den Fall mit, dass jemand auf die gleichen Fragen eingeht wie ich, wenn ich damit anfange.

In meinem Fall war es in Ordnung, mit dem Entwicklungssetup zu beginnen, bis meine neuen Server angekommen sind. Es war eine vorübergehende Situation und als meine neuen Server eintrafen, konnte ich meine Replikasets problemlos erweitern. Es gibt eine Reihe von Gründen, warum dies nicht für die Produktion empfohlen wird:

Um das Offensichtliche zu sagen, gibt es noch keine Replikation. Da ich Shards auf einer Maschine laufen ließ, gibt es einen einzigen Fehlerpunkt. Wenn der Computer oder ein Knoten ausfällt, funktioniert der Cluster nicht mehr.

Jetzt ist dieser Teil interessant. Nachdem ich einen zweiten Server hinzugefügt hatte, verfügte ich über primäre und sekundäre Knoten. Primäre Knoten wurden zum Schreiben und sekundär zum Lesen verwendet. Ich habe das Problem beseitigt, dass es keine Replikation gab und meine Daten eine höhere Verfügbarkeit hatten. Jedoch, Ich bemerkte, mit den 2-Mitglieder-Replikat-Sets, wenn ein Mitglied des Replicaset ging (auch wenn dies eine sekundäre war), trat die primäre herunter auf einen sekundären Knoten sowie. Dies hat mit dem Abstimmungsmechanismus zu tun, den MongoDb verwendet. See Markus' more detailed answer on this.. Da im Replicaset keine Primärdaten mehr vorhanden sind, funktioniert mein Cluster nicht mehr. Nun, wenn ich einen Arbiter verwenden würde, könnte ich dieses Problem ebenfalls beseitigen.

Wenn Sie ein Replikat mit drei Mitgliedern haben, wird der automatische Failover aktiviert. Wenn ein Knoten ausfällt, wird automatisch ein anderer Primärknoten zugewiesen, und der Cluster wird weiterhin wie zuvor ausgeführt.

Während meiner Tests kam ich auch zu einem Punkt, wo eine meiner MongoD.exe-Instanzen wegen einer "Out of Memory Exception" nicht mehr funktionierte. Ich habe einen Cluster mit 3 Replikasets ausgeführt, was bedeutet, dass auf jedem Computer mindestens 4 mongod.exe-Prozesse ausgeführt wurden (3 für die Replicaset-Shards und 1 für das Konfigurationsserver-Replicaset).Neben einer noch nicht optimierten Abfrage habe ich auch festgestellt, dass die WiredTiger storage engine by default can use up to 50% of ram minus one gigabyte. Vielleicht war es nicht die beste Wahl, mehrere Replicaset-Shards auf einer Maschine zu haben, aber ich war in der Lage, das Problem zu beheben, indem ich die verkettete Speicherbelegung abdeckte.

Ich hoffe, diese Antwort hilft jedem, der beginnt, Replikation und Sharding für MongoDb einzurichten.