MongoDB-Lastenausgleich in mehreren AWS-Instanzen

8

Wir verwenden Amazon Web Service für eine Geschäftsanwendung, die node.js Server und mongodb als Datenbank verwendet. Momentan läuft der node.js-Server auf einer EC2-Medium-Instanz. Und wir halten unsere mongodb-Datenbank in einer separaten Mikroinstanz. Jetzt möchten wir den Replikatsatz in unserer mongodb-Datenbank bereitstellen, sodass wir, wenn der mongodb gesperrt oder nicht verfügbar ist, unsere Datenbank weiterhin ausführen und Daten daraus abrufen können.

Wir versuchen also, jedes Mitglied des Replikatsatzes in separaten Instanzen zu halten, so dass wir Daten aus der Datenbank abrufen können, selbst wenn die Instanz des primären Members abgeschaltet wird.

Nun möchte ich den Lastenausgleich in der Datenbank hinzufügen, damit die Datenbank auch bei hoher Verkehrslast gleichzeitig funktioniert. In diesem Fall kann ich die Datenbank durch Hinzufügen von slaveOK config im replySet balancieren. Wenn die Schreiboperation in der Datenbank stark belastet wird, wird die Datenbank nicht belastet.

Um dieses Problem zu lösen, habe ich bis jetzt zwei Möglichkeiten.

Option 1: Ich muss die Datenbank sharden und jeden shard in einer separaten Instanz behalten. Und unter jedem Shard wird in derselben Instanz eine Reaplica gesetzt. Aber es gibt ein Problem, da der Shard die Datenbank in mehrere Teile teilt, so dass nicht jeder Shard dieselben Daten enthält. Wenn also eine Instanz heruntergefahren wird, können wir nicht auf die Daten aus dem Shard innerhalb dieser Instanz zugreifen.

Um dieses Problem zu lösen, versuche ich, die Datenbank in Shards zu unterteilen, und jedes Shard wird ein Replikat in separaten Instanzen haben. Selbst wenn eine Instanz heruntergefahren wird, haben wir kein Problem. Aber wenn wir 2 Shards haben und jeder Shard 3 Mitglieder im ReplicaSet hat, dann brauche ich 6 AWS-Instanzen. Also ich denke, es ist nicht die optimale Lösung.

Option 2: Wir können eine Master-Master-Konfiguration im mongodb erstellen, das bedeutet, dass die gesamte Datenbank primär ist und alle Lese- / Schreibzugriff haben, aber ich möchte auch, dass sie sich gegenseitig automatisch synchronisieren oft enden sie als Klone von einander. Und alle diese primären Datenbanken werden in einer separaten Instanz sein. Aber ich weiß nicht, ob Mongodb diese Struktur unterstützt oder nicht.

Ich habe keinen mongodb doc / blog für diese Situation. Also, bitte schlagen Sie mir vor, was die beste Lösung für dieses Problem sein sollte.

    
Indra 10.07.2014, 07:55
quelle

2 Antworten

5

Das wird bei weitem keine vollständige Antwort sein, es gibt zu viele Details und ich könnte einen ganzen Essay über diese Frage schreiben, wie es viele andere auch tun könnten, da ich keine Zeit mehr habe, werde ich es tun füge einen Kommentar hinzu über das, was ich sehe.

  

Nun möchte ich das Lastenausgleichsmodul in der Datenbank hinzufügen, so dass die Datenbank auch bei hoher Verkehrslast gleichzeitig funktioniert.

Replikatsätze sind nicht dafür ausgelegt, so zu funktionieren. Wenn Sie das Gleichgewicht laden möchten, suchen Sie vielleicht nach Sharding, was Ihnen erlaubt, dies zu tun.

Die Replikation dient dem automatischen Failover.

  

In diesem Fall kann ich die Datenbank durch Hinzufügen von slaveOK config im replySet ausbalancieren.

Um auf dem Laufenden zu bleiben, werden Ihre Mitglieder genauso viele Ops bekommen wie die Primary, es scheint, als würde das nicht zu viel helfen.

In der Realität, anstatt einen Server mit vielen Verbindungen in der Warteschlange zu haben, haben Sie viele Verbindungen auf vielen Servern, die nach veralteten Daten anstehen, da die Mitgliederkonsistenz letztendlich nicht unmittelbar im Gegensatz zu ACID-Technologien ist. ungerade ms, was bedeutet, dass sie nicht genug nacheilen, um einen vernünftigen Durchsatz zu liefern, wenn das primäre geladen wird.

Da AES gleichzeitig gelesen wird, erhalten Sie die gleiche Geschwindigkeit, unabhängig davon, ob Sie von der primären oder sekundären Seite lesen. Ich nehme an, Sie könnten einen Slave verzögern, um eine Pause von OPs zu erzeugen, aber das würde im Gegenzug massiv veraltete Daten zurückbringen.

Ganz zu schweigen davon, dass MongoDB kein Multi-Master ist, so dass man nur auf einen Knoten schreiben kann, macht slaveOK nicht mehr zur nützlichsten Einstellung der Welt und ich habe schon oft gesehen, dass 10gen selbst das Sharding-Over empfiehlt diese Einstellung.

  

Option 2: Wir können eine Master-Master-Konfiguration im mongodb erstellen,

Dies würde eine eigene Codierung erfordern. An diesem Punkt sollten Sie in Erwägung ziehen, tatsächlich eine Datenbank zu verwenden, die Ссылка

unterstützt

Dies ist, da die Geschwindigkeit, nach der Sie suchen, höchstwahrscheinlich tatsächlich in Schreibvorgängen liegt, die nicht wie oben beschrieben gelesen werden.

  

Option 1: Ich muss die Datenbank sharden und jeden shard in einer separaten Instanz behalten.

Dies ist der empfohlene Weg, aber Sie haben den Vorbehalt damit gefunden. Das ist leider etwas ungelöst, dass Multi-Master-Replikation lösen soll, jedoch fügt Multi-Master-Replikation sein eigenes Schiff von Pest-Ratten zu Europa selbst hinzu und ich würde Ihnen dringend empfehlen, ernsthafte Nachforschungen anzustellen, bevor Sie darüber nachdenken MongoDB kann derzeit Ihre Anforderungen nicht erfüllen.

Sie könnten sich wirklich um nichts sorgen, da die fsync-Warteschlange dafür ausgelegt ist, den IO-Engpass zu beheben, der Ihre Schreibvorgänge verlangsamt, wie dies in SQL der Fall wäre. Wenn Sie Ihr Schema und Arbeitssatz richtig planen, sollten Sie in der Lage sein eine riesige Menge an OPs bekommen.

Es gibt in der Tat eine verknüpfte Frage hier von einem 10gen Mitarbeiter, die sehr gut zu lesen ist: Ссылка und es zeigt, wie viel Durchsatz MongoDB unter Last erreichen kann.

Es wird bald mit der neuen Sperre auf Dokumentebene wachsen, die sich bereits in der Zweigstelle befindet.

    
Sammaye 10.07.2014 08:22
quelle
1

Option 1 ist die von @Sammaye empfohlene Methode, aber Sie benötigen nicht 6 Instanzen und können sie mit 4 Instanzen verwalten.

Angenommen, Sie benötigen die Konfiguration unten.

  • 2 Scherben (S1, S2)
  • 1 Kopie für jeden Shard (Replikatsatz sekundär) (RS1, RS2)
  • 1 Arbiter für jeden Shard (RA1, RA2)

Sie können Ihre Serverkonfiguration wie folgt unterteilen.

%Vor%

Sie könnten Arbiter-Knoten zusammen mit Ihren sekundären Knoten ausführen, was Ihnen bei der Wahl bei Ausfällen helfen würde.

    
Lalit Agarwal 10.07.2014 08:56
quelle