Ausfallsicher mit NoSQL?

In der Geschichte von Unternehmensapplikationen galt die Datenbank lange als ein unverrückbares Zentrum der Wahrheit. Sie war der Ursprung aller Daten, aber zugleich auch der Single Point of Failure. Gerade klassische relationale Datenbanken wie Microsoft SQL Server oder PostgreSQL forderten bei der Ausfallsicherheit ihren Tribut. Wer Redundanz schaffen wollte, hatte meist die Wahl zwischen einem Master-Slave-Aufbau mit manuellen Failover-Skripten oder komplexen Clustern mit Shared Storage und Virtual-IP-Routing. Der administrative Aufwand war hoch, die Gefahr eines Split-Brain-Szenarios ständiger Begleiter.

Ein großes Problem lag in der Arbeitsweise relationaler Datenbanken selbst: Sie operierten mit sequenziellen IDs, Foreign Keys und komplexen Joins – ein Modell, das bei Replikation schwer konsistent zu halten war. Gerade im Fehlerfall konnte es zu Inkonsistenzen kommen, wenn zwei Instanzen gleichzeitig neue IDs vergeben oder eine Verbindungstabelle in einem Node aktualisiert wurde, ohne dass die referenzierende Entität mitkam. Der Datenbestand wurde damit nicht nur fragmentiert, sondern schlicht unbrauchbar. Failover bedeutet in vielen Fällen nicht nur Unterbrechung, sondern auch manuelle Intervention.

Ein anderer Ansatz: MongoDBs dokumentenbasierte Philosophie

MongoDB geht grundsätzlich einen anderen Weg. Als dokumentenorientierte Datenbank ist sie nicht auf globale Sequenzen oder relationale Constraints angewiesen. Jeder Datensatz bringt seine eigene Identität mit, in Form der sogenannten ObjectId. Diese funktioniert ähnlich einer GUID, besteht aber aus einem Zeitstempel, einem Maschinen-Hash und einem zufälligen Zähler. Dadurch entsteht ein Identifier, der sowohl eindeutig als auch chronologisch sortierbar ist. Und vor allem: Er kann verteilt erzeugt werden, ohne Synchronisation zwischen Instanzen.

Diese Eigenschaft ist elementar für Hochverfügbarkeit. Denn sie erlaubt es jedem MongoDB-Node, auch im Fall eines Failovers weiterhin neue Dokumente zu speichern, ohne in Konflikt mit anderen Replikaten zu geraten. Eine zentrale Autorität für ID-Vergabe ist nicht nötig – die Architektur ist von Grund auf für Parallelität gedacht.

Clustering in MongoDB: Einfach, robust, flexibel

Ein produktiver MongoDB-Cluster besteht mindestens aus drei Instanzen, den sogenannten Replica Sets. Eine davon agiert als „Primary“, die beiden anderen als „Secondary“. Schreibzugriffe erfolgen ausschließlich über das Primary, während Leseoperationen je nach Konfiguration auch von den Secondaries verarbeitet werden können. Die Instanzen kommunizieren kontinuierlich miteinander, um den Gesundheitszustand des Clusters zu überwachen.

Fällt die Primary-Instanz aus, beginnt ein automatischer Wahlprozess: Die verbliebenen Mitglieder prüfen ihre Synchronisationsstände, stimmen ab und bestimmen eine neue Primary. Voraussetzung ist, dass eine Mehrzahl der Instanzen (das sogenannte Quorum) erreichbar ist. Damit wird verhindert, dass bei Netzwerkausfällen zwei Instanzen sich gleichzeitig für „aktiv“ halten – ein klassisches Split-Brain-Problem. Daher empfiehlt es sich, auch immer mehr als drei Instanzen zu nutzen.

Die Konfiguration eines Replica Sets ist auch für weniger datenbanknahe Entwickler nachvollziehbar. Mit wenigen CLI-Befehlen lässt sich ein Set initialisieren und erweitern:

mongo --host mongodb0.example.local --port 27017
rs.initiate(
  {
    _id : "rs0",
    members: [
      { _id: 0, host: "mongodb0.example.local:27017" },
      { _id: 1, host: "mongodb1.example.local:27017" },
      { _id: 2, host: "mongodb2.example.local:27017" }
    ]
  }
)

Hier wird ein MongoDB-Host gestartet, der in diesem Fall den Host mongodb0 hat. Dabei wird das Replica Set mittels rs.initiate und den entsprechenden Membern angegeben. Dieser Befehl wird dann auf den anderen Nodes mit entsprechender Anpassung des Hostnamens ausgeführt. Die interne Replikation erfolgt asynchron über das Write-Ahead-Log. Jeder Secondary verfolgt den Operationslog des Primarys und übernimmt alle Änderungen. Dabei hilft die ObjectId als natürlicher Ordnungsanker, da die enthaltenen Timestamps eine eindeutige Sortierung erlauben. MongoDB garantiert damit eine Eventual Consistency mit extrem kurzer Latenz – im Normalfall liegen Replikate wenige Millisekunden auseinander.

Sharding: Skalierung durch Partitionierung

Während Replica Sets primär der Ausfallsicherheit dienen, geht Sharding einen Schritt weiter: Es erlaubt die horizontale Skalierung durch Datenaufteilung. Statt alle Daten in einem einzigen Replica Set zu halten, werden sie nach definierten Schlüsseln auf verschiedene Shards verteilt. Jeder Shard ist dabei selbst ein Replica Set, was Ausfallsicherheit auf allen Ebenen ermöglicht.

Das Sharding erfolgt anhand eines sogenannten Shard Keys – einem Feld oder einer Kombination von Feldern, die für die Datenverteilung verantwortlich ist. Die Auswahl dieses Schlüssels ist entscheidend für die Performance: Ein schlechter Shard Key führt zu ungleichmäßiger Lastverteilung oder teuren Cross-Shard-Joins. Daher lohnt sich Sharding vor allem bei Applikationen mit globalem Zugriff, hoher Datenmenge und massiver Lese-/Schreib-Volumina.

Für die meisten klassischen Anwendungen reicht ein Replica Set vollkommen aus. Sharding ist ein mächtiges Werkzeug, aber auch ein Eingriff in die Datenarchitektur. Wer es einsetzt, sollte ein klares Datenmodell und Zugriffsmuster vor Augen haben.

GridFS und Chunk-basierte Replikation

Ein Spezialfall bei der Speicherung großer Dateien ist der Einsatz von GridFS – des integrierten Dateisystems von MongoDB. Hier werden Binärdaten nicht als ein Block gespeichert, sondern in einzelne Chunks zerlegt, typischerweise mit einer Größe von 255 KByte. Jeder dieser Chunks ist ein eigenes Dokument in der Datenbank und damit Bestandteil der normalen Replikation.

Der Vorteil liegt auf der Hand: Selbst wenn eine Datei mehrere Megabyte groß ist, müssen bei einer nachträglichen Änderung nur die betroffenen Teile übertragen werden. Gleichzeitig erlaubt die Chunk-Struktur eine feinere Granularität bei der Synchronisation zwischen Instanzen. In einem Failover-Szenario ist damit gewährleistet, dass auch große Dateien konsistent repliziert werden, ohne das gesamte System zu blockieren.

Auch hier helfen die ObjectIds der Chunks und deren Referenzen auf das Ursprungselement dabei, den Datenbestand sauber und rekonstruierbar zu halten. GridFS nutzt intern zwei Collections: fs.files für Metadaten und fs.chunks für die eigentlichen Datenfragmente. Diese Trennung erlaubt es, auch mit einfachen Abfragen einzelne Dateien wiederherzustellen oder gezielt Teilbereiche zu replizieren.

Skalierung in der Cloud: MongoDB Atlas

In der Cloud-Variante MongoDB Atlas entfällt ein Großteil des administrativen Aufwands. Jeder Atlas-Cluster ist automatisch ein Replica Set – inklusive Monitoring, Failover, automatischer Backups und regionaler Verteilung. Neue Instanzen lassen sich mit wenigen Klicks oder via API hinzufügen, bestehende Nodes bei Bedarf neu starten oder ersetzen.

Die manuelle Konfiguration, wie sie in On-Premises-Setups notwendig ist, übernimmt Atlas automatisch. Selbst komplexe Setups mit Sharding, dedizierten Read- und Write-Nodes oder Multi-Region-Replikation lassen sich über das Web-Interface konfigurieren. Besonders spannend für globale Anwendungen: Atlas erlaubt geobasiertes Routing, sodass Nutzeranfragen automatisch auf den nächstgelegenen Replikationsstand geleitet werden.

Hochverfügbarkeit ohne Reue

Was früher mit hohem Aufwand, Fehleranfälligkeit und tiefem Fachwissen verbunden war, lässt sich heute mit MongoDB nahezu trivial umsetzen. Replica Sets sorgen für robuste Hochverfügbarkeit, Sharding bietet Skalierung für große Datenmengen und GridFS ermöglicht selbst bei Binärdaten eine differenzierte, teilbare Speicherstrategie. Der dokumentenorientierte Ansatz vermeidet zentrale Konfliktquellen klassischer relationaler Modelle, insbesondere bei ID-Vergabe und Fremdschlüsseln.

Daher wird mit MongoDB Atlas die Hochverfügbarkeit zur Selbstverständlichkeit: Kein manuelles Clustering, keine Failover-Skripte, keine Wiederherstellungsnotfälle. Wer heute produktive Anwendungen baut, hat damit keine Ausrede mehr, auf Redundanz zu verzichten. Hochverfügbarkeit ist keine Disziplin für Spezialisten mehr, sondern ein natürlicher Bestandteil moderner Datenarchitekturen – und MongoDB liefert dafür die passende Plattform.