Fehlerbehebung bei einem MongoDB Sharded Cluster

In MongoDB erfordern große Datensätze Operationen mit hohem Durchsatz, was die Kapazität eines einzelnen Servers überfordern kann . Große Arbeitsdatensätze belasten die E/A-Kapazität von Festplattengeräten stärker und können zu Problemen wie Seitenfehlern führen.

Es gibt hauptsächlich zwei Möglichkeiten, dies zu lösen...

Vertikale Skalierung :Erhöhung der Einzelserverkapazität. Erreicht durch Hinzufügen von mehr CPU, RAM und Speicherplatz, jedoch mit einer Einschränkung, dass:die verfügbare Technologie einen einzelnen Computer möglicherweise daran hindert, für einige Arbeitslasten ausreichend leistungsstark zu sein. Praktisch gibt es ein Maximum für die vertikale Skalierung.

Horizontal Scaling Through Sharding :Dies beinhaltet die Aufteilung des Systemdatensatzes auf mehrere Server, wodurch die Gesamtarbeitslast für einen einzelnen Server reduziert wird. Um die Kapazität der Bereitstellung zu erweitern, müssen lediglich mehr Server hinzugefügt werden, um die Gesamtkosten im Vergleich zu High-End-Hardware für eine einzelne Maschine zu senken. Dies ist jedoch mit dem Nachteil verbunden, dass die Infrastruktur und Wartung für die Bereitstellung sehr komplex sein wird. Die Komplexität wird bei der Fehlerbehebung des Sharding-Clusters im Katastrophenfall noch ausgefeilter. In diesem Blog stellen wir einige der Möglichkeiten zur Fehlerbehebung bereit, die hilfreich sein können:

Shard Keys und Cluster-Verfügbarkeit auswählen

Mongos-Instanz wird nicht mehr verfügbar

Ein Mitglied verschwindet aus dem Shard-Replik-Set

Alle Mitglieder eines Replikatsatzes fehlen

Veraltete Konfigurationsdaten führen zu Cursorfehlern

Konfigurationsserver wird nicht verfügbar

Datenbank-String-Fehler behoben

Vermeiden von Ausfallzeiten beim Verschieben von Konfigurationsservern

Auswählen von Shard-Schlüsseln und Cluster-Verfügbarkeit

Sharding beinhaltet das Aufteilen von Daten in kleine Gruppen, sogenannte Shards, um die Gesamtarbeitslast für einen bestimmten Durchsatz zu reduzieren Betrieb. Diese Gruppierung wird durch die Auswahl eines optimalen Schlüssels erreicht, der hauptsächlich der wichtigste Teil vor dem Sharding ist. Ein optimaler Schlüssel sollte sicherstellen:

Mongos kann die meisten Abfragen auf einen bestimmten Mongod isolieren. Wenn beispielsweise mehrere Vorgänge einem einzelnen Shard unterliegen, werden bei einem Ausfall dieses Shards nur Daten gerendert, die damit verbunden sind, dass sie zu diesem Zeitpunkt nicht vorhanden sind. Es ist ratsam, einen Shard-Schlüssel zu wählen, der mehr Shards bereitstellt, um die Menge der nicht verfügbaren Daten zu reduzieren, falls der Shard abstürzt.

MongoDB kann die Daten gleichmäßig auf die Chunks aufteilen. Dadurch wird sichergestellt, dass die Durchsatzvorgänge auch gleichmäßig verteilt werden, wodurch die Wahrscheinlichkeit von Ausfällen aufgrund von mehr Workload-Stress verringert wird.

Schreiben Sie Skalierbarkeit über den Cluster, um eine hohe Verfügbarkeit sicherzustellen. Jeder Shard sollte insofern ein Replikat-Set sein, als wenn eine bestimmte Mongod-Instanz ausfällt, die verbleibenden Mitglieder des Replikat-Sets in der Lage sind, ein anderes Mitglied als primäres Element zu wählen und so die Betriebskontinuität sicherzustellen.

Wenn in jedem Fall ein bestimmter Shard zum Scheitern neigt, überprüfen Sie zunächst, wie viele Durchsatzvorgänge ist es ausgesetzt und erwägen Sie die Auswahl eines besseren Sharding-Schlüssels, um mehr Shards zu haben.

Was wäre wenn? Mongos-Instanz fehlt

Überprüfen Sie zuerst, ob Sie sich mit dem richtigen Port verbinden, da Sie möglicherweise unwissentlich gewechselt haben. Beispielsweise besteht bei der Bereitstellung mit der AWS-Plattform die Wahrscheinlichkeit dieses Problems aufgrund der Sicherheitsgruppen, die möglicherweise keine Verbindungen an diesem Port zulassen. Versuchen Sie für einen sofortigen Test, den vollständigen Host:Port anzugeben, um sicherzustellen, dass Sie eine Loopback-Schnittstelle verwenden. Das Gute ist, wenn jeder Anwendungsserver seine eigene Mongos-Instanz hat, können die Anwendungsserver weiterhin auf die Datenbank zugreifen. Außerdem haben Mongos-Instanzen ihren Status mit der Zeit geändert und können neu gestartet werden, ohne notwendigerweise Daten zu verlieren. Wenn die Instanz wieder verbunden wird, ruft sie eine Kopie der Konfigurationsdatenbank ab und beginnt mit dem Routing von Abfragen.

Stellen Sie sicher, dass der Port, auf dem Sie versuchen, die Verbindung wiederherzustellen, auch nicht von einem anderen Prozess belegt ist.

Was wäre wenn? Ein Mitglied wird aus dem Shard Replica Set entfernt

Überprüfen Sie zunächst den Status des Shards, indem Sie den Befehl sh.status() ausführen. Wenn das zurückgegebene Ergebnis keine Cluster-ID hat, ist der Shard tatsächlich nicht verfügbar. Untersuchen Sie immer Verfügbarkeitsunterbrechungen und -ausfälle. Wenn Sie es nicht in kürzester Zeit wiederherstellen können, erstellen Sie ein neues Mitglied, um es so schnell wie möglich zu ersetzen, um weiteren Datenverlust zu vermeiden.

Falls ein sekundäres Mitglied nicht mehr verfügbar ist, aber aktuelle Oplog-Einträge hat, kann es bei erneuter Verbindung mit dem aufholen letzten eingestellten Zustand durch Lesen der aktuellen Daten aus dem Oplog als normaler Replikationsprozess. Wenn die Daten nicht repliziert werden können, müssen Sie eine anfängliche Synchronisierung mit einer dieser beiden Optionen durchführen...

Starten Sie mongod mit einem leeren Datenverzeichnis neu und lassen Sie die Daten von der normalen anfänglichen Synchronisierungsfunktion von MongoDB wiederherstellen. Dieser Ansatz dauert jedoch lange, um die Daten zu kopieren, ist aber recht einfach.

Starten Sie den Hostcomputer mit einer Kopie eines aktuellen Datenverzeichnisses von einem anderen Mitglied im Replikatsatz neu. Schneller Prozess, aber mit komplizierten Schritten

Die anfängliche Synchronisierung ermöglicht MongoDB Folgendes:

Klont alle verfügbaren Datenbanken außer der lokale Datenbank. Stellen Sie sicher, dass das Zielmitglied über genügend Speicherplatz in der lokalen Datenbank verfügt, um die Oplog-Datensätze vorübergehend zu speichern, während die Daten kopiert werden.

Apply all changes to the data set mit dem oplog aus der Quelle. Der Vorgang ist nur abgeschlossen, wenn der Status des Replikats von STARTUP2 zu SECONDARY wechselt.

Was wäre wenn? Alle Mitglieder eines Replikatsatzes sind abwesend

In einem Shard gespeicherte Daten sind nicht verfügbar, wenn alle Mitglieder eines Replikatsatz-Shards abwesend sind. Da die anderen Shards verfügbar bleiben, sind Lese- und Schreibvorgänge weiterhin möglich, außer dass die Anwendung mit Teildaten versorgt wird. Sie müssen die Ursache der Unterbrechungen untersuchen und versuchen, den Shard so schnell wie möglich zu reaktivieren. Prüfen Sie, welcher Abfrageprofiler oder welche Methode zu diesem Problem geführt haben könnte.

Was wäre wenn? Veraltete Konfigurationsdaten führen zu Cursorfehlern

Manchmal kann es lange dauern, bis eine Mongos-Instanz den Metadaten-Cache aus der Konfigurationsdatenbank aktualisiert, was dazu führt, dass eine Abfrage zurückgegeben wird die Warnung:

could not initialize cursor across all shards because : stale config detected

Dieser Fehler wird immer angezeigt, bis die Mongos-Instanzen ihre Caches aktualisieren. Dies sollte nicht zurück an die Anwendung weitergegeben werden. Um dies zu beheben, müssen Sie die Instanz aktualisieren, indem Sie fluRouterConfig ausführen.

Um den Cache für einen bestimmten Sammlungslauf zu leeren

db.adminCommand({ flushRouterConfig: "<db.collection>" } )

Um den Cache für einen bestimmten Datenbanklauf zu leeren

db.adminCommand({ flushRouterConfig: "<db>" } )

Um den Cache für alle Datenbanken und ihre Sammlungen zu leeren, führen Sie Folgendes aus:

db.adminCommand("flushRouterConfig") db.adminCommand( { flushRouterConfig: 1 } )

Was wäre wenn? Konfigurationsserver ist nicht mehr verfügbar

Der Konfigurationsserver kann in diesem Fall als primäres Mitglied angesehen werden, von dem sekundäre Knoten ihre Daten replizieren. Wenn er abwesend ist, müssen die verfügbaren sekundären Knoten einen unter ihren Mitgliedern wählen, um der primäre zu werden. Um zu vermeiden, dass Sie möglicherweise keinen Konfigurationsserver haben, sollten Sie die Replikatsatzmitglieder auf zwei Rechenzentren verteilen seit...

Falls ein Rechenzentrum ausfällt, sind die Daten weiterhin für Lesevorgänge verfügbar und nicht für Vorgänge, wenn Sie ein einzelnes Rechenzentrum verwendet haben .

Falls das Rechenzentrum mit Minderheitsmitgliedern ausfällt, kann der Replikatsatz immer noch sowohl Schreib- als auch Lesevorgänge ausführen.

Es ist ratsam, Mitglieder auf mindestens drei Rechenzentren zu verteilen.

Eine weitere Verteilungsmöglichkeit besteht darin, die datentragenden Mitglieder gleichmäßig auf die beiden Rechenzentren zu verteilen und die restlichen Mitglieder hinein die Wolke.

Behebung des Datenbank-String-Fehlers

Ab MongoDB 3.4 werden SCCC-Konfigurationsserver für gespiegelte Mongod-Instanzen nicht unterstützt. Wenn Sie Ihren Sharding-Cluster auf Version 3.4 aktualisieren müssen, müssen Sie die Konfigurationsserver von SCCC auf CSRS konvertieren.

Vermeiden von Ausfallzeiten beim Verschieben von Konfigurationsservern

Ausfallzeiten können aufgrund einiger Faktoren wie Stromausfall oder Netzwerkfrequenzen auftreten, was zu der Ausfall eines Konfigurationsservers für den Cluster. Verwenden Sie CNAME, um diesen Server für die Umbenennung oder Neunummerierung während der Wiederverbindung zu identifizieren. Wenn der Commit-Befehl moveChunk während des Migrationsprozesses fehlschlägt, meldet MongoDB den Fehler:

ERROR: moveChunk commit failed: version is at <n>|<nn> instead of <N>|<NN>" and "ERROR: TERMINATING"

Das bedeutet, dass der Shard auch nicht mit der Konfigurationsdatenbank verbunden wurde, daher wird der primäre Server dieses Mitglied beenden um Dateninkonsistenzen zu vermeiden. Sie müssen den Chunk-Migrationsfehler unabhängig beheben, indem Sie sich an den MongoDB-Support wenden. Stellen Sie außerdem sicher, dass einige stabile Ressourcen wie Netzwerk und Stromversorgung für den Cluster bereitgestellt werden.

Fazit

Ein fragmentierter MongoDB-Cluster reduziert die Arbeitslast, der ein einzelner Server ausgesetzt gewesen wäre, wodurch die Leistung verbessert wird von Durchsatzoperationen. Wenn jedoch einige Parameter nicht korrekt konfiguriert werden, wie z. B. die Auswahl eines optimalen Shard-Schlüssels, kann dies zu einem Lastungleichgewicht führen, sodass einige Shards fehlschlagen.

Wenn die Konfiguration korrekt durchgeführt wird, können auch einige unvermeidbare Rückschläge wie Stromausfälle auftreten. Um Ihre Anwendung weiterhin mit minimaler Ausfallzeit zu unterstützen, sollten Sie mindestens 3 Rechenzentren verwenden. Wenn einer ausfällt, stehen die anderen zur Verfügung, um Leseoperationen zu unterstützen, wenn der Primärknoten unter den betroffenen Mitgliedern ist. Aktualisieren Sie Ihr System auch auf mindestens Version 3.4, da es mehr Funktionen unterstützt.