MongoDB-Betrieb im Alltag und Störungsszenarien (Replica Set und Sharded Cluster)

Keine Installation: ein szenariobasiertes Runbook, um ein installiertes MongoDB Replica Set und einen Sharded Cluster im Alltag zu betreiben und nach einem Ausfall wiederherzustellen. Health Check, Mitglieder hinzufügen/entfernen, Priority-/Hidden-/Delayed-Mitglied, Arbiter durch ein datentragendes Mitglied ersetzen, zurückgefallenes Mitglied neu synchronisieren, Force Reconfig bei Verlust der Mehrheit, geplanter stepDown, Oplog-Größe, FCV; Shards hinzufügen/entfernen, Balancer, Jumbo Chunks und reshardCollection. Wenn du nicht weißt, was zu tun ist, beginne mit dem Health Check; Restore aus dem Backup, Sicherheitseinstellungen und Major-Upgrades stehen in eigenen MongoDB-Guides.

Topologie: Replica Set (3+ Mitglieder) oder Sharded Cluster (Config Server + Shard-Replica-Sets + mongos)

Szenarien

• Health Check: Mitglieder, Verzögerung, Oplog-Fenster (bei Sharding Shards und Balancer) — Nur lesend: Mitgliederstatus, Replikationsverzögerung, Oplog-Fenster, Konfiguration; im Sharded Cluster Shard-Liste, Balancer und Chunk-Verteilung. Wenn du unsicher bist, was zu tun ist, beginne hier.
• Neues Mitglied zum Replica Set hinzufügen (Initial Sync) — Ein neuer Server ist aufgebaut (gleiche Version, Keyfile, replSetName); er wird mit priority 0 / votes 0 hinzugefügt und erhält Stimme und Priority, sobald der Initial Sync abgeschlossen und er SECONDARY ist. Keine Downtime.
• Mitglied aus dem Replica Set entfernen — Der Server wird stillgelegt oder ist dauerhaft verloren: Das Mitglied wird aus der Konfiguration entfernt und es wird geprüft, dass die verbleibenden Stimmen weiterhin eine Mehrheit bilden. Ist es der Primary, zuerst stepDown.
• Rolle eines Mitglieds ändern: Priority-, Hidden-, Delayed-Mitglied — Die Priorität eines Mitglieds für die Primary-Rolle ändern, es zum versteckten (hidden) Mitglied für Reporting/Backup oder zum verzögerten (delayed) Mitglied als Schutz vor versehentlichem Löschen machen oder es wieder normalisieren.
• Arbiter durch datentragendes Mitglied ersetzen (PSA → PSS) — Replica Set mit Primary + Secondary + Arbiter: Fällt ein Datenmitglied aus, werden Majority-Schreibvorgänge und Cache-Druck zum Problem. Ein neues Datenmitglied wird hinzugefügt und der Arbiter entfernt.
• Zurückgefallenes oder beschädigtes Mitglied neu synchronisieren (Resync) — Das Mitglied hängt in RECOVERING und meldet 'too stale to catch up', oder seine Datendateien sind beschädigt: Das Datenverzeichnis des Mitglieds wird geleert und per Initial Sync von Grund auf neu synchronisiert. Die anderen Mitglieder laufen weiter.
• Mehrheit verloren: mit den verbliebenen Mitgliedern erzwungen neu konfigurieren (Force Reconfig) — Die meisten Mitglieder sind dauerhaft verloren (Standort-/Serververlust), die verbliebenen können keinen Primary wählen: rs.reconfig(cfg, {force: true}) mit den verbliebenen Mitgliedern. Letztes Mittel; bei falscher Anwendung drohen Datenverlust und Split Brain.
• Geplanter Primary-Wechsel (rs.stepDown, bestimmtes Mitglied zum Primary machen) — Auf dem Primary-Server stehen Wartung/Patches an: Der Primary tritt zurück, ein aufgeholter Secondary wird Primary. Die Anwendung kann einige Sekunden lang Schreibfehler erhalten.
• Oplog-Größe ändern (replSetResizeOplog) — Das Oplog-Fenster ist zu kurz: Secondaries werden nach Wartungen 'too stale', das Backup kann das Oplog nicht erfassen oder es reicht nicht für eine Point-in-Time-Recovery. Es wird auf jedem Mitglied ohne Downtime vergrößert.
• Feature Compatibility Version (FCV) prüfen und abschließen — Nach dem Upgrade steht die FCV noch auf der alten Version oder die Mitglieder laufen mit unterschiedlichen Versionen: Binary-Version und FCV aller Mitglieder werden geprüft und die FCV wird auf die neue Version angehoben.
• Shard zum Cluster hinzufügen (sh.addShard) — Die Kapazität reicht nicht mehr: Ein neues Shard-Replica-Set (shardsvr) ist aufgebaut und wird zum Cluster hinzugefügt; der Balancer verschiebt die Chunks schrittweise.
• Shard entfernen (removeShard: Drain und movePrimary) — Ein Shard wird stillgelegt: Seine Chunks werden auf die anderen Shards verlagert (Drain), die Datenbanken, deren Primary Shard er ist, werden verschoben (movePrimary), danach wird er aus dem Cluster entfernt.
• Balancer: Zeitfenster, stoppen / starten, pro Collection deaktivieren — Chunk-Migrationen erzeugen Last zur Hauptlastzeit, Migrationen müssen für Wartung/Backup pausieren oder eine einzelne Collection soll nicht ausgeglichen werden.
• Ungleiche Verteilung oder Jumbo Chunks (Diagnose und Lösung) — Ein Shard ist deutlich voller als die anderen, der Balancer verschiebt nicht, es gibt als 'jumbo' markierte Chunks oder moveChunk schlägt fehl: Verteilung, Jumbo Chunks und Balancer-Fehler werden untersucht.
• Shard Key ändern (reshardCollection) — Der aktuelle Shard Key erzeugt einen Hot Shard, Jumbo Chunks oder Scatter-Gather-Abfragen: Die Collection wird online mit einem neuen Shard Key neu verteilt (5.0+). Am Ende warten Schreibvorgänge ca. 2 s.

Vor dem Start

• Auf dem Verwaltungsserver ist mongosh installiert, und er hat Namensauflösung und Portzugriff …zum mongos (…)…zu allen Mitgliedern (…)…. Die Namen in der Verbindung müssen mit den Mitgliedsnamen in rs.conf() übereinstimmen.
• Du hast das Passwort des Benutzers …; seine Rolle ist root oder mindestens clusterAdmin + readAnyDatabase.… Für eine direkte Verbindung zu einem Shard- oder Config-Server-Replica-Set ist der Shard-lokale Admin-Benutzer nötig (im Guide mongo-sharded angelegt).…
• Change-Eintrag / Wartungsfenster ist eröffnet, das Anwendungsteam informiert. Reconfig, stepDown und Shard-Operationen können eine Wahl (Election) oder Routing-Verzögerung von einigen Sekunden verursachen.
• Das neue Mitglied … wurde mit den Phasen Betriebssystem, Installation, Keyfile und Konfiguration aus dem Replica-Set-Installationsguide vorbereitet: gleiche MongoDB-Version (…), gleiches Keyfile, replication.replSetName: …, mongod läuft, aber rs.initiate wurde NICHT ausgeführt. Namensauflösung und Portzugriff zu den anderen Mitgliedern funktionieren in beide Richtungen; auf der Datenplatte ist mindestens so viel frei, wie aktuell Daten vorhanden sind.
• Während des Initial Sync werden alle Daten auf der Platte des Mitglieds neu geschrieben…; da das alte Verzeichnis beiseitegelegt wird, ist freier Platz in doppelter Datengröße nötig…. Die verbleibenden Mitglieder halten die Mehrheit, und das Oplog-Fenster des Quellmitglieds ist länger, als der Initial Sync dauern wird.

Phasen der Anleitung

• Status: Mitglieder, Verzögerung und Oplog (nur lesend) — Status und Verzögerung der Mitglieder anzeigen · Konfiguration anzeigen (priority, votes, hidden, delay) · Ergebnis auswerten und das richtige Szenario wählen
• Status: Shards, Balancer und Chunk-Verteilung (nur lesend) — Cluster-Übersicht anzeigen · Chunk-Verteilung und Jumbo Chunks · Status der Shard-Replica-Sets prüfen
• 1. Diagnose: Ist das neue Mitglied bereit? — Dienst und Version des neuen Mitglieds prüfen · Zustand und Datengröße des vorhandenen Sets ansehen · Zugriff auf das neue Mitglied prüfen
• 2. Sicherheitsnetz — Aktuelle Replica-Set-Konfiguration sichern
• 3. Anwenden: Mitglied hinzufügen und Synchronisierung abwarten — Mitglied mit priority 0 / votes 0 hinzufügen · Abschluss des Initial Sync abwarten · Dem Mitglied Stimme und Priority geben
• 4. Prüfung und Abschluss — Status prüfen · Connection Strings der Anwendung und Monitoring aktualisieren
• 1. Diagnose: Ist das zu entfernende Mitglied der Primary, bleibt die Mehrheit erhalten? — Rolle des Mitglieds und verbleibende Stimmenzahl ermitteln
• 2. Sicherheitsnetz — Aktuelle Replica-Set-Konfiguration sichern
• 3. Anwenden: Mitglied entfernen — Mitglied aus der Konfiguration entfernen (rs.remove) · mongod auf dem entfernten Server stoppen
• 4. Prüfung und Abschluss — Status prüfen · Connection Strings, Monitoring und Firewall aktualisieren
• 1. Diagnose — Aktuelle Einstellungen des Mitglieds und Oplog-Fenster ansehen
• 2. Sicherheitsnetz — Aktuelle Replica-Set-Konfiguration sichern
• 3. Durchführung — Mitgliedseinstellung ändern (rs.reconfig)
• 4. Prüfung — Ergebnis prüfen
• 1. Diagnose: Arbiter und neues Mitglied — Arbiter und Write Concern ansehen · Bereitschaft des neuen Mitglieds prüfen
• 2. Sicherheitsnetz — Aktuelle Replica-Set-Konfiguration sichern
• 3. Anwenden: Datenmitglied hinzufügen, Arbiter entfernen — Neues Mitglied mit priority 0 / votes 0 hinzufügen · Abschluss des Initial Sync abwarten · Dem neuen Mitglied Stimme und Priority geben · Arbiter entfernen · mongod auf dem Arbiter-Server stoppen
• 4. Prüfung und Abschluss — Status und Write Concern prüfen
• 1. Diagnose: Muss das Mitglied wirklich neu synchronisiert werden? — Status und letzte Meldung des Mitglieds ansehen · Fehler im Log des Mitglieds ansehen
• 2. Sicherheitsnetz — Aktuelle Replica-Set-Konfiguration sichern
• 3. Anwenden: Datenverzeichnis leeren und Initial Sync — mongod stoppen · Datenverzeichnis …beiseitelegen…leeren… · mongod starten (Initial Sync beginnt) · Abschluss des Initial Sync abwarten
• 4. Prüfung und Abschluss — Status prüfen · Altes Datenverzeichnis löschen
• 1. Diagnose: Ist die Mehrheit wirklich dauerhaft verloren? — Status und Optimes auf einem verbliebenen Mitglied ansehen · Prüfen, dass die verlorenen Mitglieder heruntergefahren sind
• 2. Sicherheitsnetz — Konfiguration des verbliebenen Mitglieds sichern
• 3. Anwenden: Force Reconfig — Nur mit den verbliebenen Mitgliedern erzwungen neu konfigurieren · Prüfen, dass ein Primary gewählt wurde
• 4. Prüfung und Abschluss — Majority-Schreibvorgang testen · Verlorene Mitglieder wieder hinzufügen und Ursache beheben
• 1. Diagnose: Haben die Secondaries aufgeholt? — Primary und Verzögerungen ansehen
• 2. Anwenden — Andere Secondaries einfrieren (damit das Zielmitglied gewählt wird) · Primary zurücktreten lassen (rs.stepDown)
• 3. Verifikation — Neuen Status prüfen
• 1. Diagnose: aktuelle Oplog-Größe und Oplog-Fenster — Oplog-Größe und Oplog-Fenster auf jedem Mitglied