5 häufige MongoDB-Fehlerszenarien und schnelle Lösungen

Die Fehlerbehebung bei MongoDB beginnt normalerweise, wenn Ihre App langsam wird, Schreibvorgänge fehlschlagen oder ein Replikatset zurückfällt. Diese Anleitung führt durch fünf häufige Szenarien, die Sie wahrscheinlich in der Produktion sehen werden, und zeigt, wo Sie zuerst suchen sollten.

Verwenden Sie diese Überprüfungen als ersten Durchgang, bevor Sie größere Änderungen vornehmen. Sie helfen Ihnen, Abfrageprobleme von Infrastruktur-, Replikations- oder Sharding-Problemen zu trennen.

1. Langsame Abfrageleistung

Langsame Abfragen sind vielleicht das häufigste Leistungsproblem, das in Produktionsumgebungen gemeldet wird. Eine Abfrage, die Sekunden statt Millisekunden dauert, kann die Reaktionsfähigkeit der Anwendung erheblich beeinträchtigen.

Diagnose: Verwendung von explain()

Der erste Schritt bei der Diagnose einer langsamen Abfrage besteht darin, zu verstehen, warum sie langsam ist. Die explain()-Methode von MongoDB ist das wesentliche Werkzeug für diese Analyse. Sie zeigt den Ausführungsplan und detailliert, welche Indizes verwendet wurden (oder nicht verwendet wurden).

Befehlsbeispiel:

db.collection.find({ field: 'value' }).explain('executionStats')

Analysieren Sie die Ausgabe und achten Sie insbesondere auf:

• winningPlan.stage: Wenn die Stufe COLLSCAN ist, liest MongoDB jedes Dokument. Das deutet oft auf einen fehlenden oder nicht verwendbaren Index hin.
• executionStats.nReturned im Vergleich zu executionStats.totalKeysExamined und executionStats.totalDocsExamined.

Schnelle Lösungen

1. Erstellen Sie den richtigen Index: Wenn der Abfrageplan einen Collection-Scan zeigt, fügen Sie einen Index hinzu, der dem Filter- und Sortiermuster entspricht. Wenn Ihre App beispielsweise häufig Bestellungen nach user_id und neuestem timestamp durchsucht, erstellen Sie einen zusammengesetzten Index:

db.orders.createIndex({ user_id: 1, timestamp: -1 }) ``` 2. Verfeinern Sie die Abfrage: Überprüfen Sie, ob Sie zu viele Daten abrufen. Verwenden Sie die Projektion, um nur die Felder zurückzugeben, die die Seite oder der Job tatsächlich benötigt. 3. Überprüfen Sie die Protokolle langsamer Abfragen: Verwenden Sie den Profiler oder das Protokoll langsamer Abfragen mit einem Schwellenwert, der zu Ihrer Arbeitslast passt. Behandeln Sie jeden genauen Schwellenwert als eine betriebliche Entscheidung, nicht als universelle Regel.

Tipp: Indizes verbessern die Lesegeschwindigkeit, verlangsamen aber Schreibvorgänge geringfügig. Indizieren Sie nur Felder, die häufig in Abfrageprädikaten (find()), Sortieroperationen (sort()) oder Bereichsabfragen verwendet werden.

2. Replikationsverzögerung in Replikatsets

Eine Replikationsverzögerung tritt auf, wenn sekundäre Mitglieder eines Replikatsets bei der Anwendung von Operationen aus dem Oplog (Operationsprotokoll) erheblich hinter dem primären Mitglied zurückbleiben.

Diagnose: Überprüfung von replSetGetStatus

Verwenden Sie den Befehl replSetGetStatus auf einem beliebigen Mitglied des Replikatsets, um den Zustand und den Synchronisationsstatus aller Mitglieder zu überprüfen.

Befehlsbeispiel:

rs.printReplicationInfo()
// Oder direkte Abfrage des Status:
rs.status()

Suchen Sie nach der optimeDate für das primäre und die sekundären Mitglieder. Die Differenz zwischen der Optime des primären und der Optime eines sekundären Mitglieds gibt die Verzögerung an, die normalerweise im Feld secsBehind für jedes Mitglied angezeigt wird.

Schnelle Lösungen

1. Überprüfen Sie die Netzwerklatenz: Hohe Latenz zwischen den Mitgliedern kann die Oplog-Übertragung verlangsamen.
2. Überprüfen Sie das zurückgebliebene sekundäre Mitglied: Hohe CPU, langsame Datenträger-E/A oder laute Nachbar-Workloads können verhindern, dass ein sekundäres Mitglied Schreibvorgänge schnell genug anwendet.
3. Überprüfen Sie die Oplog-Abdeckung: Wenn die Verzögerung schwerwiegend ist, hat das sekundäre Mitglied möglicherweise nicht mehr die benötigten Oplog-Einträge. In diesem Fall müssen Sie dieses Mitglied möglicherweise neu synchronisieren oder neu aufbauen.

3. Verbindungsfehler und Authentifizierungsfehler

Anwendungsdienste können aufgrund von Konfigurationsfehlern, Firewall-Problemen oder falschen Anmeldeinformationen häufig keine Verbindung zu MongoDB herstellen.

Diagnose: Überprüfung von Protokollen und Netzwerk

Überprüfen Sie zunächst, ob der MongoDB-Server auf der erwarteten IP-Adresse und dem erwarteten Port lauscht. Überprüfen Sie die MongoDB-Serverprotokolle auf spezifische Fehler.

Häufige Protokollfehler:

• Address already in use: Ein anderer Prozess verwendet den Port.
• Connection refused: Der Serverprozess ist ausgefallen, blockiert oder lauscht woanders.
• Authentication failed: Der Benutzername, das Passwort, die Authentifizierungsdatenbank oder die Rollenzuweisung ist falsch.

Schnelle Lösungen

1. Überprüfen Sie die Firewall-Regeln: Stellen Sie sicher, dass der MongoDB-Port, oft 27017, von den Anwendungshosts aus erreichbar ist.
2. Überprüfen Sie bindIp: Wenn mongod.conf nur an 127.0.0.1 bindet, können sich entfernte Clients nicht verbinden. Binden Sie wenn möglich an eine bestimmte private Schnittstelle. Vermeiden Sie 0.0.0.0, es sei denn, Netzwerkkontrollen und Authentifizierung sind bereits vorhanden.
3. Überprüfen Sie authSource: Wenn der Benutzer in admin erstellt wurde, muss die Verbindungszeichenfolge möglicherweise ?authSource=admin enthalten.

4. Speicherplatzmangel

Als Dokumentendatenbank speichert MongoDB Daten direkt auf der Festplatte. Unerwartetes Datenwachstum oder unsachgemäß durchgeführte Datenbankbereinigungen können schnell zu Speicherplatzmangel führen und alle Schreibvorgänge stoppen.

Diagnose: Überwachung und db.stats()

Verwenden Sie Betriebssystem-Überwachungstools (df -h unter Linux), um die gesamte Speichernutzung zu überprüfen. Verwenden Sie innerhalb von MongoDB den Befehl db.stats(), um zu sehen, wie viel Speicherplatz einzelne Datenbanken verbrauchen.

Befehlsbeispiel:

db.stats()

Achten Sie insbesondere auf die Felder storageSize und dataSize.

Schnelle Lösungen

1. Zeit gewinnen, wenn Schreibvorgänge fehlschlagen: Stoppen Sie nicht wesentliche Jobs, entfernen Sie nicht zusammenhängende temporäre Dateien oder erweitern Sie das Volume, wenn Ihre Plattform dies unterstützt.
2. Entfernen Sie ungenutzte Daten: Löschen Sie alte Collections oder Datenbanken erst, nachdem Sie bestätigt haben, dass sie nicht mehr benötigt werden und Backups vorhanden sind.
3. Komprimieren Sie vorsichtig: Bei Collections mit vielen Lösch- oder Aktualisierungsvorgängen kann compact reservierten Speicherplatz freigeben, aber es kann störend sein. Testen Sie die Auswirkungen für Ihre MongoDB-Version und Ihr Speicherengine:

db.myCollection.runCommand({ compact: 'myCollection' }) ``` 4. Erhöhen Sie die Speicherkapazität: Die langfristige Lösung sind in der Regel größere Festplatten, bessere Aufbewahrungsregeln oder separater Speicher für Protokolle und Backups.

Warnung: Wenn die Festplatte vollständig voll ist, stoppt MongoDB das Schreiben, um Datenbeschädigungen zu verhindern. Sie müssen Speicherplatzprobleme beheben, bevor Sie versuchen, den normalen Betrieb wieder aufzunehmen.

5. Sharding-Cluster-Fehler (Veraltete Router/Konfigurationsserver)

In sharding-Umgebungen können Konnektivitäts- oder Zustandsprobleme innerhalb der Konfigurationsserver (config servers) oder Abfrage-Router (mongos-Instanzen) das gesamte System zum Stillstand bringen.

Diagnose: Überprüfung des Cluster-Zustands

Der Befehl sh.status(), der gegen eine mongos-Instanz ausgeführt wird, ist das primäre Diagnosetool für den Sharding-Zustand.

Beispiel für einen umsetzbaren Befehl:

sh.status()

Wichtige Bereiche, die in der Ausgabe zu überprüfen sind:

• Konfigurationsserver: Bestätigen Sie, dass das Konfigurationsserver-Replikatset eine gesunde Mehrheit hat.
• Shards: Überprüfen Sie, ob jeder aufgeführte Shard verbunden ist und korrekt meldet.
• Veralteter Status: Achten Sie auf Warnungen, dass ein Router oder Shard veraltete Metadaten hat.

Schnelle Lösungen

1. Starten Sie mongos bei Bedarf neu: Wenn ein Router veraltet oder nicht reagiert, kann ein Neustart eine neue Verbindung zu den Konfigurationsservern erzwingen.
2. Beheben Sie zuerst die Gesundheit des Konfigurationsservers: Wenn dem Konfigurationsserver-Replikatset eine gesunde Mehrheit fehlt, können Shard-Metadatenoperationen fehlschlagen.
3. Beheben Sie Probleme auf Shard-Ebene: Wenn ein Shard aufgrund von Speicherplatzmangel oder Replikationsverzögerung ausgefallen ist, beheben Sie diese Ursache, bevor Sie Router-Symptomen nachgehen.

Wann Sie einen Fachmann hinzuziehen sollten

Ziehen Sie einen MongoDB-Administrator oder Plattformingenieur hinzu, wenn Datenverlust möglich ist, ein Replikatset neu synchronisiert werden muss, Konfigurationsserver nicht gesund sind oder Speicherplatz bereits Schreibvorgänge beeinträchtigt. Holen Sie sich Hilfe, bevor Sie störende Befehle wie Komprimierung oder Mitgliederneuaufbau in der Produktion ausführen.

Fazit

Beginnen Sie die MongoDB-Fehlerbehebung mit dem Symptom, das dem Benutzer am nächsten ist: langsame Seite, fehlgeschlagene Verbindung, blockierter Schreibvorgang, zurückgebliebenes sekundäres Mitglied oder Fehler im sharding-Cluster. Verwenden Sie dann explain(), rs.status(), db.stats() und sh.status(), um die Ursache zu bestätigen, bevor Sie Indizes ändern, Router neu starten oder Mitglieder neu aufbauen.