Fehlerbehebung bei MongoDB-Replikationsverzögerungen: Ursachen und Lösungen

MongoDB-Replikationsverzögerungen beginnen meist als kleine betriebliche Unannehmlichkeit. Ein Diagramm beginnt zu steigen. Ein Secondary fällt 15 Sekunden zurück, dann 2 Minuten. Jemand fragt, ob die Lesevorgänge veraltet sind. Jemand anderes schlägt vor, den Knoten neu zu starten. Bevor Sie das tun, verlangsamen Sie und finden Sie heraus, welcher Teil der Replikation zurückfällt.

MongoDB-Secondaries kopieren Operationen aus dem Oplog des Primaries und wenden sie lokal an. Replikationsverzögerung bedeutet, dass ein Secondary Operationen nicht so aktuell angewendet hat wie der Primary. Dies kann Secondary-Reads, Backups von Secondaries, Analyse-Jobs und Failover beeinträchtigen. Es kann auch ein größeres Risiko verbergen: Wenn der Secondary weiter zurückfällt als das Oplog-Fenster, kann er möglicherweise gar nicht mehr aus dem Oplog aufholen.

Der schnellste Weg zur Fehlerbehebung besteht darin, drei Fragen zu beantworten:

• Hinkt jeder Secondary hinterher oder nur einer?
• Ist die Verzögerung vorübergehend, stetig oder wachsend?
• Befindet sich der Secondary noch innerhalb des Oplog-Fensters?

Diese Antworten bestimmen, was Sie als Nächstes tun.

Verzögerung messen ohne Raten

Beginnen Sie in mongosh:

rs.status()

Finden Sie den Primary und vergleichen Sie dessen optimeDate mit dem optimeDate jedes Secondaries. Achten Sie auch auf ungesunde Mitglieder, Heartbeat-Nachrichten und Mitglieder, die in Zuständen wie RECOVERING oder STARTUP2 feststecken.

Für eine freundlichere Zusammenfassung führen Sie aus:

rs.printSecondaryReplicationInfo()

Einige ältere Materialien verwenden rs.printSlaveReplicationInfo(). Wenn Sie ältere Systeme warten, sehen Sie möglicherweise noch diesen Helfer. Die moderne Bezeichnung ist "Secondary".

Überprüfen Sie dann das Oplog-Fenster:

rs.printReplicationInfo()

Das Oplog-Fenster ist die Menge an Verlauf, die derzeit im Oplog aufbewahrt wird. Wenn Ihr Secondary 40 Minuten zurückliegt und das Oplog-Fenster mehrere Tage beträgt, haben Sie Spielraum für die Fehlerbehebung. Wenn Ihr Secondary 40 Minuten zurückliegt und das Oplog-Fenster während der Spitzenlast 1 Stunde beträgt, sind Sie nahe an einer Wiederherstellungssituation.

Verlassen Sie sich nicht nur auf SecondsBehind-Werte aus einem einzigen Tool. Taktversatz, verzögerte Mitglieder und kurze Ausbrüche können eine einzelne Zahl irreführend machen. Vergleichen Sie die Statusausgabe mit Überwachungsdiagrammen für Schreibvolumen, Festplattenlatenz, CPU und Netzwerkdurchsatz.

Wenn alle Secondaries hinterherhinken

Wenn jeder Secondary ungefähr zur gleichen Zeit zurückfällt, liegt die Ursache normalerweise upstream von einem einzelnen Secondary. Betrachten Sie zuerst die Schreiblast des Primaries.

Häufige Auslöser sind:

• Bulk-Imports oder Backfills.
• Große updateMany- oder deleteMany-Operationen.
• TTL-Bereinigung nach einer Phase des Rückstaus.
• Anwendungsbereitstellungen, die das Schreibvolumen geändert haben.
• Indexerstellungen oder Schema-Wartung.
• Ein plötzlicher Anstieg kleiner Schreibvorgänge, die viele Oplog-Einträge erzeugen.

Fragen Sie, was sich zum Zeitpunkt des Beginns der Verzögerung geändert hat. Ein Anstieg, der genau dann beginnt, wenn ein nächtlicher Job startet, ist selten ein MongoDB-Rätsel.

Überprüfen Sie auf dem Primary aktive Operationen:

db.currentOp({ active: true })

Wenn Sie einen Batch-Job finden, erwägen Sie, ihn zu drosseln, anstatt ihn mit maximaler Geschwindigkeit abschließen zu lassen. Verarbeiten Sie beispielsweise Dokumente in _id-Bereichen, pausieren Sie zwischen Batches und beobachten Sie die Verzögerung. Dies ist besonders nützlich für Bereinigungsjobs, bei denen es weniger wichtig ist, in 30 Minuten fertig zu sein, als das Replica Set gesund zu halten.

Wenn das anhaltende Schreibvolumen einfach höher ist, als das Replica Set verarbeiten kann, benötigen Sie eine Kapazitäts- oder Architekturänderung. Bessere Festplatten, mehr CPU, eine andere Instanzklasse, Optimierung des Schreibpfads oder Sharding können die richtige Antwort sein. Die Änderung der Read Preference wird einen Primary nicht reparieren, der mehr Arbeit produziert, als das Set anwenden kann.

Wenn nur ein Secondary hinterherhinkt

Ein einzelner zurückfallender Secondary deutet normalerweise auf ein lokales Problem hin. Melden Sie sich an diesem Host an und überprüfen Sie die Grundlagen:

iostat -xz 1
vmstat 1
top

Innerhalb von MongoDB verwenden Sie:

mongostat --host secondary.example.com:27017
mongotop --host secondary.example.com:27017

Die Festplatte ist ein häufiger Übeltäter. Ein Secondary, der langsameren Speicher als der Primary verwendet, kann bei normalem Datenverkehr in Ordnung sein und dann bei Ausbrüchen zurückfallen. Cloud-Volumes können auch Durchsatz- oder IOPS-Grenzen erreichen. Achten Sie auf hohe Auslastung, hohe Wartezeiten und Warteschlangen.

CPU kann wichtig sein, wenn die Arbeitslast viele Updates, Komprimierung, Verschlüsselung oder hohen Abfrageverkehr auf demselben Mitglied umfasst. Speicherdruck ist wichtig, wenn der Secondary heiße Daten und Indizes nicht im Cache halten kann, während er Schreibvorgänge anwendet.

Überprüfen Sie auch, was sonst noch auf dem Host läuft. Backups, Antivirenscans, Dateisystem-Snapshots, Log-Komprimierung und Berichtsabfragen können alle mit der Replikation konkurrieren. Wenn der zurückfallende Knoten auch der "sichere Ort" ist, an dem jeder Ad-hoc-Analysen durchführt, haben Sie wahrscheinlich das Problem gefunden.

Lesevorgänge auf Secondaries können Verzögerungen verursachen

Secondary-Reads sind nicht kostenlos. Sie verwenden denselben Cache, dieselbe CPU und dieselbe Festplatte, die die Replikation benötigt. Eine einzelne Aggregation, die eine große Sammlung scannt, kann ausreichen, um einen Secondary während einer geschäftigen Periode zurückfallen zu lassen.

Suchen Sie nach lang laufenden Lesevorgängen:

db.currentOp({ active: true })

Wenn die Anwendung Lesevorgänge an Secondaries sendet, überprüfen Sie die Read Preference. secondary kann Lesevorgänge an zurückfallende Mitglieder erzwingen. secondaryPreferred kann immer noch veraltete Daten zurückgeben. Verwenden Sie für Benutzerabläufe, die ihre eigenen Schreibvorgänge lesen müssen, den Primary. Für letztendlich konsistente Lesevorgänge setzen Sie maxStalenessSeconds, damit der Treiber Secondaries vermeidet, die zu weit zurückliegen.

Erwägen Sie für Berichtsworkloads einen versteckten Secondary oder eine separate Analyse-Pipeline. Versteckte Mitglieder können weiterhin replizieren, aber Treiber werden sie nicht für normale Lesevorgänge auswählen. Das macht sie zu einem besseren Ort für Backups oder kontrollierte Berichts-Jobs, solange Sie sie richtig dimensionieren.

Oplog-Größe ist eine Wiederherstellungsmarge, keine Geschwindigkeitskorrektur

Ein zu kleines Oplog verursacht normalerweise nicht selbst Verzögerungen. Es macht Verzögerungen gefährlich. Wenn ein Secondary zurückfällt und die benötigten Oplog-Einträge überschrieben werden, kann er nicht normal aufholen.

Ihr Oplog-Fenster sollte länger sein als Ihre realistischen Ausfall- und Wartungsszenarien. Wenn ein Secondary während des Patchens 6 Stunden offline sein kann, reicht ein 4-stündiges Oplog-Fenster nicht aus. Wenn ein vierteljährlicher Import das Oplog in wenigen Stunden durchbrennt, dimensionieren Sie für diese Arbeitslast oder ändern Sie, wie der Import läuft.

Ändern Sie auf unterstützten Versionen die Größe mit replSetResizeOplog auf jedem Mitglied, das ein größeres Oplog benötigt:

use admin
db.adminCommand({ replSetResizeOplog: 1, size: 20480 })

Dieses Beispiel fordert etwa 20 GB an. Verwenden Sie in verwalteten Plattformen die verwaltete Konfigurationsmethode. Vermeiden Sie alte Ratschläge, die das Oplog löschen und neu erstellen, es sei denn, Sie folgen einem sorgfältig getesteten Wiederherstellungsverfahren.

Nachdem Sie das Oplog vergrößert haben, beheben Sie weiterhin die zugrunde liegende Verzögerung. Ein größeres Oplog gibt Ihnen mehr Zeit; es entfernt keine Festplattensättigung, Netzwerkbeschränkungen oder übermäßige Schreibausbrüche.

Netzwerkprüfungen, die tatsächlich helfen

Netzwerkprobleme treten eher auf, wenn die Verzögerung einen entfernten Secondary, eine Verfügbarkeitszone oder einen Rechenzentrumspfad betrifft. Beginnen Sie einfach:

ping primary.example.com
traceroute primary.example.com

Schauen Sie dann über die Latenz hinaus. Die Replikation benötigt zuverlässigen Durchsatz. Paketverlust, Firewall-Inspektion, VPN-Beschränkungen, regionsübergreifende Bandbreitenbegrenzungen oder überlastete Netzwerkschnittstellen können Verzögerungen verursachen, selbst wenn Ping akzeptabel aussieht.

Wenn nur das regionsübergreifende Mitglied zurückfällt, vergleichen Sie es mit einem lokalen Secondary unter derselben Schreiblast. Möglicherweise benötigen Sie eine andere Topologie, eine größere Verbindung oder eine klarere Erwartung, dass entfernte Mitglieder für die Notfallwiederherstellung und nicht für frische Lesevorgänge gedacht sind.

Daten- und Indexdrift

Replica-Set-Mitglieder sollten dieselben Indizes haben. Wenn nicht, kann die Oplog-Anwendung verlangsamt werden oder fehlschlagen. Dies kommt normalerweise von manuellen Änderungen, fehlgeschlagener Wartung oder einem Mitglied, das aus einer inkonsistenten Quelle wiederhergestellt wurde.

Vergleichen Sie Indizes für heiße Sammlungen:

db.orders.getIndexes()

Führen Sie es auf dem Primary und auf dem zurückfallenden Secondary aus. Wenn die Definitionen abweichen, beheben Sie die Drift gezielt. Das Neuerstellen eines großen Index kann zusätzliche Last verursachen, planen Sie es daher sorgfältig oder erstellen Sie das Mitglied aus einer sauberen Quelle neu, wenn die Unterschiede weit verbreitet sind.

Datenabweichung ist schwerwiegender. Wenn Replikationsfehler fehlende Datensätze oder doppelte Schlüssel anzeigen, ist die Verzögerung nicht mehr das einzige Problem. Sie müssen den Fehler untersuchen, Daten vergleichen und entscheiden, ob eine Reparatur auf Tabellenebene, eine Resynchronisation oder eine vollständige Neuerstellung der sicherste Weg ist.

Seien Sie konservativ mit Neustarts und Initial Sync

Das Neustarten eines zurückfallenden Secondaries hilft manchmal, wenn der Prozess hinter einem vorübergehenden Problem feststeckt. Es ist keine universelle Lösung. Wenn das Mitglied nahe am Rand des Oplog-Fensters ist, kann ein Neustart genug Zeit kosten, um es in einen nicht wiederherstellbaren Zustand zu versetzen.

Überprüfen Sie vor dem Neustart:

• Aktuelle Verzögerung.
• Aktuelles Oplog-Fenster.
• Ob das Mitglied synchronisiert.
• Ob andere gesunde Secondaries existieren.
• Ob das Replica Set es tolerieren kann, dass das Mitglied ausfällt.

Initial Sync ist die saubere Antwort, wenn ein Secondary nicht aufholen kann oder seine Daten nicht vertrauenswürdig sind. Es ist auch schwer. Es kopiert Daten, erstellt Indizes und verbraucht Ressourcen von einem anderen Mitglied. Bauen Sie jeweils ein Mitglied neu auf und stellen Sie sicher, dass Ihre Abstimmungskonfiguration weiterhin sichere Wahlen unterstützt, während der Knoten neu aufgebaut wird.

Wann Sie nicht überstürzt eingreifen sollten

Etwas Verzögerung ist während kontrollierter Arbeiten zu erwarten. Wenn Sie einen geplanten Backfill durchführen, einen Secondary wiederherstellen oder historische Daten importieren, ist die nützliche Frage, ob der Secondary mit einer akzeptablen Rate aufholt. Ein Verzögerungsdiagramm, das 20 Minuten lang ansteigt und dann stetig fällt, erfordert möglicherweise keinen Eingriff. Ein Verzögerungsdiagramm, das jeden Tag ansteigt und nie zur Baseline zurückkehrt, schon.

Diese Unterscheidung ist wichtig, weil einige Korrekturen störend sind. Das Abbrechen eines Batch-Jobs kann Anwendungsdaten halb aktualisiert hinterlassen. Das Neustarten eines Secondaries kann die Cache-Wärme kosten und das Aufholen verlangsamen. Das Neuerstellen eines Mitglieds kann mehr Netzwerk und Festplatte verbrauchen, als einfach den Rückstand anzuwenden.

Setzen Sie für geplante Jobs ein Verzögerungsbudget, bevor der Job beginnt. Sie könnten beispielsweise entscheiden, dass ein Wartungs-Backfill bis zu 10 Minuten Verzögerung auf einem Reporting-Secondary verursachen darf, aber nicht auf einem Failover-Kandidaten. Beobachten Sie die Verzögerung, das Oplog-Fenster und die Schreibrate, während der Job läuft. Wenn der Job sich dem Budget nähert, pausieren Sie ihn oder reduzieren Sie die Batch-Größe.

Es hilft auch, benutzerorientierte Replikate von Wartungsreplikaten zu trennen. Ein Secondary, der für Anwendungslesevorgänge verwendet wird, sollte eine strengere Verzögerungstoleranz haben als ein verstecktes Mitglied, das für Backups verwendet wird. Wenn jeder Secondary eine andere Aufgabe hat, sollten die Alarmgrenzwerte diese Aufgaben widerspiegeln, anstatt eine Zahl für das gesamte Set zu verwenden.

Was während eines Vorfalls aufgezeichnet werden sollte

Replikationsvorfälle sind viel einfacher im Nachhinein zu verstehen, wenn Sie die richtigen Beweise speichern. Bevor Sie die Konfiguration ändern, erfassen Sie:

rs.status()
rs.conf()
rs.printReplicationInfo()
rs.printSecondaryReplicationInfo()

Speichern Sie auch Host-Level-Metriken vom Primary und dem zurückfallenden Secondary: Festplattenlatenz, CPU, Speicher und Netzwerkdurchsatz. Wenn ein Batch-Job oder eine Bereitstellung lief, zeichnen Sie dessen Startzeit und Befehl oder Release-Version auf.

Dies ist kein Selbstzweck. Ohne eine Zeitleiste beginnt der nächste Vorfall bei Null. Mit einer Zeitleiste stellen Sie möglicherweise fest, dass die Verzögerung immer einem bestimmten Export, Backup oder Bereinigungsaufgabe folgt. Das verwandelt ein vages Datenbankproblem in ein planbares Kapazitätsproblem.

Eine praktische Lösungskarte

Verwenden Sie das Symptom, um den nächsten Schritt zu wählen:

Symptom	Wahrscheinlicher Bereich	Nächste Aktion
Alle Secondaries hinken während eines Batch-Jobs hinterher	Schreibausbruch	Job drosseln oder aufteilen
Ein Secondary hinkt immer hinterher	Lokales Ressourcenproblem	Festplatte, CPU, Speicher und lokale Lesevorgänge überprüfen
Verzögerung wächst nur auf entferntem Mitglied	Netzwerk/Topologie	Durchsatz, Paketverlust und regionsübergreifendes Design überprüfen
Verzögerung nahe am Oplog-Fenster	Wiederherstellungsrisiko	Oplog vergrößern und Verzögerungsquelle reduzieren
Secondary liefert veraltete Lesevorgänge	Read Preference	Primary für frische Lesevorgänge verwenden oder maxStalenessSeconds setzen
Mitglied kann nach Ausfallzeit nicht aufholen	Fehlende Oplog-Historie	Aus Backup neu erstellen oder Initial Sync

Gute MongoDB-Replikationsfehlerbehebung ist meist disziplinierte Beobachtung. Finden Sie heraus, ob der Primary zu viel Arbeit produziert, der Secondary zu langsam anwendet oder die Verbindung zwischen ihnen eingeschränkt ist. Ändern Sie dann das, was die Replikation tatsächlich begrenzt, anstatt einen generischen Neustart, eine Resynchronisation oder eine Konfigurationsanpassung anzuwenden.