☰

MongoDB auf AWS (EBS): 3 Replikate vs. 2 Replikate + Arbiter

tag-icon • tag-icon replication mongodb
MongoDB auf AWS (EBS): 3 Replikate vs. 2 Replikate + Arbiter

Wir haben eine ziemlich große Mongo-Datenbank in AWS laufen. Derzeit verwenden wir einen Replikationssatz mit 3 Instanzen. Jede Instanz verfügt über 5 TB angeschlossenen EBS-Speicher. Das entspricht über 1000 USD/Monat pro Instanz. Darüber hinaus haben wir sowohl eine Produktions- als auch eine Staging-Umgebung (eine dritte „Entwicklungs“-Umgebung kommt bald). Darüber hinaus werden diese Kosten in Zukunft explodieren, wenn/falls wir zu einer Sharding-Umgebung wechseln.

Die Frage ist, wie notwendig sind 3 Replikate in einer AWS-Umgebung?

Ok, ok, ok, ich weiß bereits, dass die Antwort „es kommt darauf an“ lautet. Ich suche nach Ratschlägen, wie man die Kompromisse am besten abwägt. Zum Beispiel …

  1. Wenn man bedenkt, dass jedes EBS-Volume bereits über eine dreifache Redundanz verfügt und die Wiederherstellung aus einem Backup relativ einfach ist, stellt sich die Frage: Wie messe ich die zusätzliche Fehlertoleranz von 2 gegenüber 3 Replikaten?

  2. Gibt es bei der Abwägung der Kompromisse neben der Redundanz noch weitere Überlegungen?

  3. Hat jemand Erfahrung (gute oder schlechte) mit dem Ausführen von nur 2 Replikaten + einem Arbiter?

Antwort1

  1. Wenn man bedenkt, dass jedes EBS-Volume bereits über eine dreifache Redundanz verfügt und die Wiederherstellung aus einem Backup relativ einfach ist, stellt sich die Frage: Wie messe ich die zusätzliche Fehlertoleranz von 2 gegenüber 3 Replikaten?

Bei MongoDB bestehen die wichtigsten Überlegungen bei nur zwei datentragenden Mitgliedern in einem Replikationssatz mit drei Knoten darin, dass, wenn eines dieser datentragenden Mitglieder aus irgendeinem Grund (geplante Wartung oder ungeplanter Ausfall) nicht verfügbar ist, Folgendes gilt:

  • Sie verfügen nicht mehr über eine aktive Replikation (es ist nur noch ein datentragendes Mitglied übrig)
  • Ihre Bereitstellung kann keine Schreibbedenken mehr berücksichtigen, die höher sind als w:1(zum Beispiel: w:majorityoder w:2).

Diese Konfiguration bietet eine hohe Verfügbarkeit hinsichtlich der Aufrechterhaltung/Auswahl eines Primärservers im Falle des Ausfalls eines einzelnen Mitglieds, der Schiedsrichter beeinträchtigt jedoch die Datenredundanz, wenn eines Ihrer datentragenden Mitglieder nicht verfügbar ist. Vorausgesetzt, Sie haben ausreichend Zeit, um Ihre EBS-Backups wiederherzustellen (und vertrauen auf die EBS-Redundanz), kann dies für Ihren Anwendungsfall ein akzeptabler Kompromiss sein.

  1. Gibt es bei der Abwägung der Kompromisse neben der Redundanz noch weitere Überlegungen?

Wenn Ihr Code MongoDB verwendetAnliegen schreibenhöher als der Standardwert ( w:1) ist, sollten Sie einenwtimeoutWert. Wenn Sie die Option nicht angeben wtimeoutund die Schreibbedenkenstufe nicht erreichbar ist, werden Schreibvorgänge auf unbestimmte Zeit blockiert.

AWS-Garantien für redundante Infrastrukturen erstrecken sich im Allgemeinen nur auf Ausfälle über mehrere Verfügbarkeitszonen hinweg. Um die Verfügbarkeit zu maximieren, sollten Sie Ihre Replikatsatzmitglieder daher auch in unterschiedlichen Verfügbarkeitszonen bereitstellen.

  1. Hat jemand Erfahrung (gut oder schlecht) mit dem Betrieb von nur 2 Replikaten + einem Arbiter

Ich habe definitiv schlechte Ergebnisse gesehen, wenn Benutzer die oben genannten Punkte nicht berücksichtigt haben (insbesondere im Hinblick auf Schreibprobleme und Timeouts). Wenn Sie diese Vorbehalte bei der Planung (und beim Testen) berücksichtigen, sollten Sie gute Erfahrungen machen können.

Darüber hinaus verfügen wir über eine Produktions- und eine Staging-Umgebung (eine dritte „Dev“-Umgebung kommt bald).

Es gibt definitiv ein Argument für prod-ähnliche Staging- und Entwicklungsumgebungen, aber eine typische Kostenersparnis wäre die Bereitstellung von Umgebungen mit niedrigeren Spezifikationen für die Entwicklung mit weniger Failover als die Produktion. Für das Staging möchten Sie möglicherweise Umgebungen mit niedrigeren Spezifikationen bereitstellen, aber eine ähnliche Konfiguration haben, damit Sie realistische Failover-Szenarien testen können. Wenn Sie Leistungs- oder Belastungstests in Stagingumgebungen durchführen, sollten diese mit denselben Spezifikationen wie die Produktion bereitgestellt werden.

verwandte Informationen