Diagnose und Behebung häufiger Probleme mit MongoDB-Replikationsverzögerungen

MongoDB-Replikationsverzögerung ist nicht nur eine Zahl auf einem Dashboard. Sie verändert das Verhalten Ihrer Anwendung. Ein Benutzer aktualisiert ein Profil, eine andere Anfrage liest von einem Secondary, und der alte Wert kommt zurück. Ein Knoten fällt aus, aber der beste Secondary hinkt noch hinterher, sodass der Failover länger dauert als erwartet. Eine Berichtsabfrage landet auf dem falschen Mitglied, und plötzlich sieht das Replica Set gesund aus, bis auf einen Secondary, der sich ständig vom Primary entfernt.

Die nützliche Art, über Replikationsverzögerung nachzudenken, ist einfach: Der Primary produziert Oplog-Einträge schneller, als ein oder mehrere Secondaries sie abrufen und anwenden können. Die Lösung hängt davon ab, welche Seite dieses Satzes in Ihrer Umgebung zutrifft. Manchmal schreibt der Primary in Schüben zu viel. Manchmal ist der Secondary unterdimensioniert. Manchmal ist das Netzwerk langsam. Manchmal ist die Verzögerung beabsichtigt, weil das Mitglied mit secondaryDelaySecs konfiguriert ist. Ihre erste Aufgabe ist es, diese Fälle zu unterscheiden, bevor Sie Änderungen vornehmen.

Beginnen Sie mit der tatsächlichen Form der Verzögerung

Beginnen Sie nicht damit, die Oplog-Größe zu ändern oder mongod neu zu starten. Finden Sie zuerst heraus, ob die Verzögerung stetig, spitz, auf ein Mitglied beschränkt ist oder alle Secondaries betrifft.

In mongosh beginnen Sie mit:

rs.status()

Schauen Sie sich die Felder stateStr, optimeDate, lastHeartbeatMessage und health jedes Mitglieds an. Wenn ein Secondary hinterherhinkt und die anderen aktuell sind, haben Sie wahrscheinlich ein mitgliedsspezifisches Problem: Festplatte, CPU, lokale Lesevorgänge, lokale Wartung oder einen schlechten Netzwerkpfad. Wenn alle Secondaries hinterherhinken, untersuchen Sie genauer das primäre Schreibvolumen, den Netzwerkdurchsatz vom Primary oder einen ungewöhnlich großen Vorgang.

Für eine schnelle Überprüfung des Oplog-Fensters führen Sie aus:

rs.printReplicationInfo()

Das Oplog-Fenster gibt an, wie viel Zeit vom aktuellen Oplog abgedeckt wird. Es sagt nicht aus, dass die Replikation gesund ist. Es sagt, wie weit ein Secondary zurückfallen kann, bevor er Gefahr läuft, eine initiale Synchronisation zu benötigen. Wenn Ihr Oplog-Fenster 6 Stunden beträgt und Ihre Wartungsfenster routinemäßig 8 Stunden dauern, haben Sie ein echtes operationelles Risiko, selbst wenn die aktuelle Verzögerung null ist.

Für Secondaries ist auch dies nützlich:

rs.printSecondaryReplicationInfo()

In älteren Beispielen sehen Sie möglicherweise rs.printSlaveReplicationInfo(). Neuere Formulierungen verwenden "secondary", aber ältere Shell-Helfer und ältere Blogbeiträge verwenden möglicherweise noch "slave". Die Felder sind wichtiger als der Name.

Wenn Sie ein kleines Skript für eine Live-Shell wünschen, vergleichen Sie die Primary-Optime mit jedem Secondary:

const status = rs.status();
const primary = status.members.find(m => m.stateStr === "PRIMARY");

status.members
  .filter(m => m.stateStr === "SECONDARY")
  .forEach(m => {
    const lagSeconds = (primary.optimeDate - m.optimeDate) / 1000;
    print(`${m.name}: ${lagSeconds}s hinter Primary`);
  });

Behandeln Sie dies als eine Momentaufnahme, nicht als Diagnose. Ein Secondary, der während eines Batch-Imports 20 Sekunden hinterherhinkt, kann in Ordnung sein, wenn er schnell aufholt. Ein Secondary, der bei normalem Datenverkehr ständig 20 Sekunden hinterherhinkt, verdient Aufmerksamkeit.

Überprüfen Sie, ob die Verzögerung beabsichtigt ist

Bevor Sie einen falschen Vorfall verfolgen, überprüfen Sie die Replica-Set-Konfiguration:

rs.conf()

Ein verzögertes Mitglied ist so konfiguriert, dass es dem Primary mit Absicht hinterherhinkt. In der modernen MongoDB-Konfiguration suchen Sie nach secondaryDelaySecs bei einem Mitglied. Dieses Mitglied ist für einige Wiederherstellungsszenarien nützlich, da es für einen kurzen Zeitraum eine ältere Ansicht der Daten bewahren kann. Es sollte nicht für frische Lesevorgänge verwendet werden, und seine erwartete Verzögerung sollte von normalen Verzögerungsalarmen ausgeschlossen werden.

Der Fehler, den ich im realen Betrieb sehe, ist, jedes verzögerte Mitglied zu alarmieren, als ob es defekt wäre. Alarmieren Sie bei Verzögerung über die konfigurierte Verzögerung hinaus. Wenn ein Mitglied um 1 Stunde verzögert ist und 1 Stunde und 5 Minuten Verzögerung anzeigt, beträgt die tatsächliche Verzögerung etwa 5 Minuten.

Wenn das Oplog-Fenster zu klein ist

Das Oplog ist eine gedeckelte Sammlung in der local-Datenbank. Secondaries lesen es und wenden die Operationen der Reihe nach an. Wenn ein Secondary so weit zurückfällt, dass der Primary nicht mehr die benötigten Oplog-Einträge hat, ist ein gewöhnliches Aufholen nicht mehr möglich. Das Mitglied benötigt normalerweise eine initiale Synchronisation oder eine Wiederherstellung aus einem geeigneten Backup.

Deshalb ist das Oplog-Fenster wichtig. Sie möchten, dass es mehr abdeckt als Ihre erwarteten Ausfallzeiten, Wartungsarbeiten, Netzwerkunterbrechungen und Spitzen-Schreiblasten. Es gibt keine universelle "richtige" Oplog-Größe. Ein ruhiger Cluster kann Tage der Geschichte in einem kleinen Oplog aufbewahren. Ein ausgelasteter Cluster mit vielen Aktualisierungen kann dieselbe Größe in kurzer Zeit verbrauchen.

Wenn das Oplog-Fenster während des Spitzenverkehrs schrumpft, vergrößern Sie es vor dem nächsten Wartungsfenster. Verwenden Sie bei unterstützten MongoDB-Versionen replSetResizeOplog, anstatt local.oplog.rs zu löschen und neu zu erstellen. Das Löschen des Oplogs auf einem Replica-Set-Mitglied ist ein risikoreicher Wiederherstellungsmanöver, kein normaler Optimierungsschritt.

Führen Sie den Größenänderungsbefehl auf dem Mitglied aus, dessen Oplog Sie ändern möchten:

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

Der size-Wert ist in Megabyte. Ein Wert von 10240 bedeutet ungefähr 10 GB. Ändern Sie die Größe jedes Mitglieds nach Bedarf. In verwalteten Umgebungen wie MongoDB Atlas verwenden Sie den unterstützten Konfigurationspfad der Plattform, anstatt direkte Dateisystem- oder Prozesskontrolle anzunehmen.

Überprüfen Sie nach der Größenänderung das neue Fenster unter realer Schreiblauf. Ein größeres Oplog verringert die Wahrscheinlichkeit, aus dem Oplog zu fallen, aber es lässt einen langsamen Secondary nicht schneller Operationen anwenden.

Wenn ein Secondary langsam ist

Wenn nur ein Secondary hinterherhinkt, melden Sie sich auf diesem Host an und untersuchen Sie die üblichen Systemsymptome. MongoDB wird oft für das verantwortlich gemacht, was in Wirklichkeit eine Festplattensättigung ist.

Verwenden Sie Tools wie:

iostat -xz 1
vmstat 1
top
mongostat --host secondary.example.com:27017
mongotop --host secondary.example.com:27017

Hohe Festplattenauslastung, hohe Wartezeiten oder eine lange E/A-Warteschlange bedeuten normalerweise, dass der Secondary nicht schnell genug schreiben kann. Dies kann passieren, wenn für Secondaries ein günstigerer Instanztyp verwendet wird, wenn EBS- oder Netzwerkspeicher eine geringere bereitgestellte Durchsatzrate hat oder wenn Backups und Dateisystem-Snapshots gleichzeitig mit Spitzen-Anwendungsschreibvorgängen ausgeführt werden.

CPU kann ebenfalls eine Rolle spielen, insbesondere bei Komprimierung, Verschlüsselung, Dokumentverschiebungen, Indexwartung oder einer Arbeitslast mit vielen kleinen Aktualisierungen. Speicherdruck zeigt sich als Seitenfehler, Cache-Verschleiß und ein Secondary, der ständig von der Festplatte liest, während er versucht, Oplog-Einträge anzuwenden.

Die praktische Lösung ist normalerweise langweilig: Geben Sie dem Secondary Speicher und CPU vergleichbar mit dem Primary, reduzieren Sie konkurrierende Arbeit auf diesem Host oder verschieben Sie schwere Lesevorgänge woanders hin. Ein Replica-Set-Mitglied ist keine kostenlose Berichtskapazität. Es muss immer noch mit der Replikation Schritt halten.

Wenn Lesevorgänge auf Secondaries das Problem verursachen

Leseskalierung mit Secondaries ist nützlich, aber es ist leicht, es zu übertreiben. Eine Dashboard-Abfrage, die eine große Sammlung scannt, kann mit der Oplog-Anwendung konkurrieren. Der Secondary akzeptiert möglicherweise weiterhin Lesevorgänge, aber die Replikation fällt zurück, weil dieselbe CPU, derselbe Cache und dieselbe Festplatte für Benutzerabfragen verwendet werden.

Überprüfen Sie den Profiler und die aktuellen Operationen auf dem verzögerten Mitglied:

db.currentOp({ active: true })

Wenn Sie lange Lesevorgänge, Aggregationsjobs oder Wartungsskripte sehen, entscheiden Sie, ob dieser Secondary diese Arbeitslast wirklich bedienen sollte. Für Berichte kann ein versteckter oder dedizierter Secondary besser geeignet sein. Für Anwendungslesevorgänge setzen Sie maxStalenessSeconds, damit der Treiber Secondaries vermeidet, die zu weit zurück sind.

Für konsistenzkritische Pfade verwenden Sie Primary-Lesevorgänge. Beispiele sind Anmeldestatus, Checkout-Bestätigung, Passwortänderungen, Kontoeinstellungen und alles, bei dem ein Benutzer erwartet, seinen eigenen Schreibvorgang sofort zu lesen. Secondary-Lesevorgänge sind am besten für Daten geeignet, bei denen eine kurze Veralterung akzeptabel ist.

Wenn der Primary Schübe produziert

Große Schreibvorgänge können gesunde Secondaries kaputt aussehen lassen. Massenimporte, breite Multi-Dokument-Updates, TTL-Bereinigung, große Löschvorgänge und Indexänderungen können einen Schub von Oplog-Aktivitäten erzeugen, dessen Anwendung Zeit in Anspruch nimmt.

Suchen Sie nach kürzlichen Operationen auf dem Primary:

db.currentOp({ active: true })

Überprüfen Sie auch Anwendungsbereitstellungen, Datenreparaturjobs, Backfills und geplante Aufgaben. Replikationsverzögerung, die genau um 02:00 Uhr beginnt, ist oft nicht mysteriös. Es ist ein Batch-Job.

Wenn Sie den Job kontrollieren, teilen Sie ihn in kleinere Stücke auf. Aktualisieren Sie beispielsweise Dokumente nach _id-Bereichen, pausieren Sie zwischen Batches und beobachten Sie die Verzögerung, während der Job läuft. Mit bulkWrite können ungeordnete Schreibvorgänge den Durchsatz verbessern, aber die Fehlerbehandlung muss explizit sein, da Fehler teilweise auftreten können. Das Ziel ist nicht immer, den Primary so schnell wie möglich fertig werden zu lassen. Das Ziel ist, das Replica Set die Arbeit absorbieren zu lassen, ohne seine Wiederherstellungsmarge zu verlieren.

Indizes und Oplog-Anwendung

In einem normalen Replica Set werden Indizes repliziert. Wenn sich Indizes zwischen Mitgliedern aufgrund manueller Arbeit, fehlgeschlagener Wartung oder eines falsch wiederhergestellten Knotens unterscheiden, kann ein Secondary schmerzhaft langsam werden, wenn es Aktualisierungen und Löschvorgänge anwendet. Die Oplog-Operation muss möglicherweise ein Dokument finden, und ohne den erwarteten Index kann der Secondary viel mehr Arbeit leisten als der Primary.

Vergleichen Sie Indexdefinitionen für die betroffenen Sammlungen:

db.orders.getIndexes()

Führen Sie denselben Befehl auf dem Primary und dem verzögerten Secondary aus. Wenn sie sich unterscheiden, finden Sie heraus, warum, bevor Sie weitere Änderungen vornehmen. Das Neuerstellen eines großen Index kann selbst Last erzeugen, planen Sie es daher während einer ruhigen Periode oder bauen Sie das Mitglied aus einer bekannten guten Quelle neu auf, wenn die Abweichung groß ist.

Verwenden Sie keine alten Ratschläge, die besagen, dass Hintergrund-Indexerstellungen alle Replikationsbedenken lösen. Das Verhalten der MongoDB-Indexerstellung hat sich zwischen Versionen geändert, und die richtige operationelle Wahl hängt von Ihrer Version und Topologie ab. Verwenden Sie die aktuelle Serverdokumentation für die genaue Version, die Sie ausführen.

Netzwerkprobleme sind normalerweise woanders sichtbar

Netzwerkverzögerung zeigt sich tendenziell als instabile Heartbeats, intermittierende Fehler oder schlechter Durchsatz zwischen bestimmten Hosts oder Regionen. Grundlegende Überprüfungen helfen immer noch:

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

Aber eine niedrige Ping-Latenz beweist nicht genügend Bandbreite. Die Replikation kann durch Durchsatz, Paketverlust, Firewall-Inspektion, regionsübergreifende Verbindungen oder lautes gemeinsames Netzwerk eingeschränkt werden. Wenn die Verzögerung nur bei einem entfernten Secondary auftritt, vergleichen Sie ihn mit einem Secondary in derselben Region wie der Primary. Wenn Mitglieder in derselben Region in Ordnung sind und das entfernte Mitglied hinterherhinkt, verlangt die Topologie möglicherweise zu viel von der Verbindung.

Seien Sie bei regionsübergreifenden Replica Sets ehrlich über den Kompromiss. Sie können bei der Notfallwiederherstellung helfen, sind aber anfälliger für Latenz- und Bandbreitenbeschränkungen. Wenn das entfernte Mitglied für Lesevorgänge gedacht ist, verwenden Sie Veralterungskontrollen und testen Sie das Failover-Verhalten, anstatt anzunehmen, dass es sich wie ein lokaler Secondary verhält.

Seien Sie vorsichtig mit Neustart- und Resync-Ratschlägen

Ein Neustart von mongod kann ein vorübergehendes Problem beheben, kann aber einen Vorfall verschlimmern, wenn der Knoten kurz davor war, aus dem Oplog zu fallen. Überprüfen Sie vor einem Neustart das Oplog-Fenster und die aktuelle Verzögerung. Wenn der Knoten zwei Stunden zum Aufholen benötigt und das Oplog-Fenster während des Spitzenverkehrs nur drei Stunden beträgt, kann ein langer Neustart zu einer initialen Synchronisation anstelle eines Aufholens führen.

Die initiale Synchronisation ist eine gültige Reparaturoption, wenn ein Secondary veraltet, beschädigt ist oder die erforderliche Oplog-Historie fehlt. Sie ist auch teuer. Sie kopiert Daten, erstellt Indizes und verbraucht Netzwerk- und Festplattenressourcen von Synchronisationsquellen. In der Produktion ziehen Sie es vor, jeweils ein Mitglied hinzuzufügen oder neu aufzubauen, damit das Replica Set genügend stimmberechtigte und datentragende Mitglieder behält, um Ausfälle zu tolerieren.

Wenn ein Mitglied so weit zurück ist, dass es nicht aufholen kann, wählen Sie einen frischen Backup- oder Snapshot-basierten Pfad, der Ihren operationellen Standards entspricht. Löschen Sie kein Datenverzeichnis, nur weil eine Checkliste es sagt. Bestätigen Sie, dass das Mitglied entbehrlich ist, bestätigen Sie, dass das Replica Set den Neubau tolerieren kann, und bestätigen Sie, dass Sie genügend Oplog-Fenster oder eine zuverlässige initiale Synchronisationsquelle haben.

Alarmieren Sie basierend auf dem, was Benutzer und Betreiber betrifft

Ein guter Alarm ist nicht "Replikationsverzögerung ist größer als 1 Sekunde" für jedes System. Einige Anwendungen tolerieren 30 Sekunden bei Analyse-Lesevorgängen. Andere tolerieren keine veralteten Lesevorgänge bei Kontoständen. Alarmschwellen sollten den Anwendungsfall widerspiegeln.

Nützliche Alarme umfassen:

• Replikationsverzögerung über der Anwendungstoleranz für einen längeren Zeitraum.
• Oplog-Fenster unter dem längsten erwarteten Wartungs- oder Wiederherstellungsintervall.
• Ein Secondary in RECOVERING, STARTUP2 oder in einem ungesunden Zustand länger als erwartet.
• Festplatten-E/A-Sättigung auf einem datentragenden Mitglied.
• Heartbeat-Fehler oder Netzwerkfehler zwischen Mitgliedern.

Dashboards sollten die Verzögerung neben dem Schreibvolumen, der Festplattenlatenz, der CPU, dem Speicherdruck und dem Netzwerkdurchsatz anzeigen. Die Verzögerung allein sagt Ihnen, dass es ein Problem gibt. Die benachbarten Diagramme sagen Ihnen normalerweise, welches Problem.

Eine praktische Triage-Reihenfolge

Wenn Sie Bereitschaft haben, verwenden Sie diese Reihenfolge:

1. Bestätigen Sie mit rs.status(), welche Mitglieder hinterherhinken.
2. Überprüfen Sie, ob eine Verzögerung aufgrund von secondaryDelaySecs beabsichtigt ist.
3. Überprüfen Sie das Oplog-Fenster mit rs.printReplicationInfo().
4. Vergleichen Sie die Verzögerung mit Schreibspitzen, Batch-Jobs und kürzlichen Bereitstellungen.
5. Untersuchen Sie die Festplatte, CPU, den Speicher und die lokale Abfragelast des verzögerten Secondarys.
6. Überprüfen Sie Netzwerkfehler und Latenz zwischen den betroffenen Mitgliedern.
7. Entscheiden Sie, ob das Mitglied aufholen kann, ob Last entfernt werden muss, ob mehr Ressourcen benötigt werden oder ob es neu aufgebaut werden muss.

Das beste Ergebnis ist normalerweise kein dramatischer Befehl. Es ist, den Engpass zu finden und zu beseitigen, ohne Datenabweichungen zu erzeugen. MongoDB-Replikationsverzögerung ist handhabbar, wenn Sie sie als Kapazitäts- und Topologiesignal behandeln, nicht als allgemeinen MongoDB-Fehler.