Die MongoDB-Bereitstellung in der Produktion kann nur dann wirklich funktionieren, wenn das richtige Bereitstellungsmuster eingehalten wird. Die Bereitstellung eines Replikatsatzes auf einem einzelnen Host garantiert nicht die hohe Verfügbarkeit von Daten. Der Umgang mit Big Data erfordert umfangreiche Recherchen und optimale Implementierungen, entweder durch Kombination der verfügbaren Optionen oder durch Auswahl derjenigen mit den vielversprechendsten Vorteilen.
Bereitstellungsmuster für MongoDB umfassen:
- Replica Sets mit drei Mitgliedern
- Replikatsätze verteilt auf zwei oder mehr Rechenzentren.
Replik-Sets mit drei Mitgliedern
Replikation ist eine Skalierungsstrategie für MongoDB, die die Hochverfügbarkeit von Daten verbessert. Ein Replikatsatz beinhaltet:
- Ein primärer Knoten:verantwortlich für alle Schreibdurchsatzoperationen und von dem auch gelesen werden kann.
- Sekundäre Knoten:Können nur für Lesevorgänge verwendet werden, können aber als primär ausgewählt werden, falls der vorhandene Knoten ausfällt. Sie beziehen ihre Datenaktualisierungen aus einem Oplog, das vom primären Mitglied des Satzes generiert wird.
- Schiedsrichter. Wird verwendet, um die Wahl eines Primärs zu erleichtern, falls es eine gerade Anzahl von Replikat-Set-Mitgliedern gibt. Es hostet keine Kopie der Daten.
Vorteile eines Replica Sets können nur bei einer Mindestanzahl von drei Mitgliedern mit folgender Architektur erreicht werden:
Primär-Sekundär-Sekundär
Dies wird am meisten empfohlen, da es eine größere Fehlertoleranz hat und die Beschränkungen des Hinzufügens eines dritten datentragenden Elements, wie z. B. Kosten, anspricht.
Bei dieser Bereitstellung werden neben den Primärdaten immer zwei vollständige Kopien bereitgestellt, wodurch eine hohe Verfügbarkeit sichergestellt wird. Ein Ausfall des primären Servers veranlasst den Replikatsatz, einen neuen primären Server zu wählen, und der Serving-Vorgang wird wie gewohnt fortgesetzt. Wenn das alte primäre Mitglied lebendig wird, wird es als sekundäres Mitglied kategorisiert.
Während des Wahlvorgangs signalisieren sich die Mitglieder einander durch einen Herzschlag und während dieser Zeit finden keine Schreibvorgänge statt
Nach dem Wahlprozess gehen wir von der zu reformierenden Architektur aus:
Primär-Sekundär-Arbiter
Dies stellt sicher, dass der Replikatsatz auch dann verfügbar bleibt, wenn der primäre oder sekundäre nicht verfügbar ist, indem der Wahlprozess eines sekundären zu einem primären erleichtert wird. Arbiter führen keine Kopie der Daten mit sich und benötigen daher weniger Ressourcen für die Verwaltung.
Eine Einschränkung bei dieser Bereitstellung ist; keine Redundanz, da es nur zwei datentragende Elemente gibt:primär und sekundär. Dies führt zu einer geringeren Fehlertoleranz.
Fehlertoleranz sollte sicherstellen können:
- Schreibverfügbarkeit:Die Mehrheit der stimmberechtigten Mitglieder des Replikatsatzes ist erforderlich, um die primäre Person zu verwalten oder zu wählen, die für die Schreibvorgänge verantwortlich ist.
- Datenredundanz:Schreibvorgänge können von mehreren Mitgliedern bestätigt werden, um Rollbacks zu vermeiden
Die Primary-Secondary-Arbiter-Konfiguration unterstützt den Aspekt der Schreibverfügbarkeit nur so, dass, wenn ein einzelnes Mitglied des Satzes nicht verfügbar ist, immer noch ein Primary beibehalten werden kann.
Die Nichtunterstützung des zweiten Aspekts führt jedoch zu einigen betrieblichen Konsequenzen, wenn das sekundäre Mitglied nicht verfügbar ist:
- Es findet keine aktive Replikation statt, insbesondere wenn die Sekundärseite längere Zeit offline ist. Wenn der sekundäre Server zu lange offline ist, kann er aus dem Oplog herausfallen, was einen dazu zwingt, ihn während des Neustarts neu zu synchronisieren.
- Datenredundanz wird sabotiert, wodurch erzwungen wird, dass Schreiboperationen nur von der aktuellen Primärdatenbank bestätigt werden.
- Die Option „Mehrheit mit Bedenken“ stellt den verbundenen Anwendungen und internen Prozessen nicht die neuesten Daten zur Verfügung. Dies ist der Fall, wenn Ihre Konfiguration erwartet, dass Schreibvorgänge eine Mehrheitsbestätigung anfordern und daher blockiert werden, bis die Mehrheit der datentragenden Mitglieder verfügbar ist.
- Die Chunk-Migration zwischen Shards wird auch beeinträchtigt, wenn der Replikatsatz Teil eines Sharding-Clusters ist.
- Druck auf den WiredTiger-Speicher-Engine-Cache, wenn Rollbacks auftreten und der Mehrheits-Commit-Punkt nicht vorgerückt werden kann.
Um diese Folgen zu vermeiden, kann man sich für eine Primär-Sekundär-Sekundär-Konfiguration entscheiden, da dies die Fehlertoleranz erhöht.
Hinweis:Fehlertoleranz tritt nicht nur im Fehlerfall ein, sondern auch einige Systemoperationen wie Software-Upgrades und normale Wartung können dazu führen, dass ein Mitglied kurzzeitig nicht verfügbar ist.
Über zwei oder mehr Rechenzentren verteilte Replikatsätze
Hochverfügbarkeit kann auf eine andere Ebene gehoben werden, indem Replikatsatzmitglieder auf geografisch unterschiedliche Rechenzentren verteilt werden. Dieser Ansatz erhöht die Redundanz und gewährleistet eine hohe Fehlertoleranz für den Fall, dass ein Rechenzentrum nicht verfügbar ist.
Wenn sich alle Mitglieder in einem einzigen Rechenzentrum befinden, ist der Replikatsatz anfällig für Rechenzentrumsausfälle wie Netzwerktransienten und Stromausfälle.
Es ist ratsam, mindestens ein Mitglied in einem alternativen Rechenzentrum zu halten, Verwenden Sie eine ungerade Anzahl von Rechenzentren und wählen Sie eine Verteilung von Mitgliedern, die eine Mehrheit für die Wahl bietet oder im Falle eines Scheiterns mindestens eine Kopie der Daten bereitstellt.
Die Konfiguration sollte sicherstellen, dass beim Ausfall eines Rechenzentrums der Replikatsatz beschreibbar bleibt, da die verbleibenden Mitglieder eine Wahl abhalten können.
Verteilen Sie Ihre Daten auf mindestens drei Rechenzentren.
Mitglieder können auf Ressourcen beschränkt sein oder Netzwerkbeschränkungen haben, was sie ungeeignet macht, im Falle eines Failovers primär zu werden. Sie können diese Mitglieder so konfigurieren, dass sie nicht primär werden, indem Sie ihnen die Priorität 0 geben.
Mitglieder in einem Rechenzentrum können eine höhere Priorität als andere Rechenzentren haben, um ihnen eine Abstimmungspriorität zu geben, so dass sie primär vor Mitgliedern in anderen Rechenzentren wählen können.
Alle Mitglieder im Replica Set sollten in der Lage sein, miteinander zu kommunizieren.
Fazit
Die Replikationsvorteile können auf einen vielversprechenderen Status angehoben werden, indem die Mitglieder auf mehrere Rechenzentren verteilt werden. Dies erhöht neben der Sicherstellung der Datenredundanz wesentlich die Ausfallsicherheit. Replica Set-Mitglieder bieten, wenn sie auf zwei oder mehr Rechenzentren verteilt sind, Vorteile gegenüber einem einzelnen Rechenzentrum, wie zum Beispiel:
Falls eines der Rechenzentren ausfällt, sind die Daten im Gegensatz zu einer Verteilung auf ein einzelnes Rechenzentrum immer noch für Lesevorgänge verfügbar.
Schreibvorgänge können immer noch bestätigt werden, wenn ein Rechenzentrum mit Minderheitsmitgliedern ausfällt.
Lesevorgänge können immer noch möglich sein, wenn das Rechenzentrum mit mehrheitlich abstimmenden Mitgliedern ausfällt, anders als bei einem einzelnen Rechenzentrum.
