Zum Hauptinhalt springen

Datenbank

Einführung

Datenbankreplikation ist ein kritischer Bestandteil der ausfallsicheren Passwork-Architektur. Sie hält die Daten über alle Knoten synchron. Wenn der Primary-Knoten ausfällt, stimmen die verbleibenden Knoten ab, um einen neuen Primary zu wählen, den die Anwendungsserver automatisch verwenden.

Abstimmungsmechanismus

Funktionsweise

  1. Jeder Knoten hat eine Stimme — jeder Knoten kann an der Wahl des Primary teilnehmen.
  2. Quorum — die Wahl eines neuen Primary erfordert eine Mehrheit (>50%) der Stimmen.
  3. Automatische Wahl — wenn der aktuelle Primary ausfällt, stimmen die Knoten automatisch ab.
  4. Datensynchronisation — der neue Primary muss über aktuelle Daten verfügen.

Warum die Knotenanzahl wichtig ist

Mindestanzahl der Knoten: 3

Um ausfallsicher zu bleiben, verwenden Sie eine ungerade Anzahl von Knoten (3, 5, 7) im Replica Set.

Warum 2 Knoten nicht ausreichen

  • Mit 2 Knoten: Wenn einer ausfällt, kann der verbleibende Knoten kein Quorum erreichen (50% reicht nicht aus; es werden >50% benötigt).
  • Mit 3 Knoten: Wenn einer ausfällt, bilden die verbleibenden 2 Knoten eine Mehrheit (66%) und können einen neuen Primary wählen.

Warum eine ungerade Anzahl bevorzugt wird

Bei einer geraden Anzahl von Knoten (zum Beispiel 4) besteht das Risiko eines Split-Brain-Szenarios:

  • Wenn das Netzwerk in zwei Teile mit jeweils 2 Knoten geteilt wird, kann keine Seite eine Mehrheit erreichen (>50% erforderlich).
  • Beide Teile wechseln in den schreibgeschützten Modus, und das System wird nicht verfügbar.

Beispielproblem mit 4 Knoten:

         ┌─────────────────────────────────────────────────────────────────────────┐
│ NETWORK SPLIT │
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ Node #1 │ │ Node #2 │ │ Node #3 │ │ Node #4 │ │
│ │ │ │ │ │ │ │ │ │
│ │ Vote: 1 │ │ Vote: 1 │ │ Vote: 1 │ │ Vote: 1 │ │
│ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │
│ │ │ │ │ │
│ └─────────────────┘ └─────────────────┘ │
│ │ │ │
│ Part 1: 2 nodes (50%) Part 2: 2 nodes (50%) │
│ — Cannot elect Primary — Cannot elect Primary │
│ — Read-only mode — Read-only mode │
│ — Passwork unavailable — Passwork unavailable │
└─────────────────────────────────────────────────────────────────────────┘

Konfigurationsvergleich:

Knoten1 Knoten fällt ausNetzwerkteilungEmpfehlung
2SchreibgeschütztSchreibgeschütztNicht empfohlen
3FunktioniertFunktioniert (2 von 3)Mindestempfehlung
4FunktioniertSchreibgeschützt (2 und 2)Nicht empfohlen
5FunktioniertFunktioniert (3 von 5)Empfohlen
6FunktioniertSchreibgeschützt (3 und 3)Nicht empfohlen
7FunktioniertFunktioniert (4 von 7)Empfohlen

Abstimmungsdiagramm

         ┌─────────────────────────────────────────────────────────────────┐
│ REPLICA SET │
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ Node #1 │ │ Node #2 │ │ Node #3 │ │
│ │ (Primary) │ │ (Secondary) │ │ (Secondary) │ │
│ │ │ │ │ │ │ │
│ │ Vote: 1 │ │ Vote: 1 │ │ Vote: 1 │ │
│ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │
│ │ │ │ │
│ └─────────────────┼─────────────────┘ │
│ │ │
│ Voting between nodes │
│ (Quorum: 2 of 3 = majority) │
└─────────────────────────────────────────────────────────────────┘

Betriebsszenarien

Normaler Betrieb (3 Knoten):

  • Primary verarbeitet alle Lese- und Schreibvorgänge.
  • Secondary-Knoten synchronisieren sich mit dem Primary.
  • Alle Knoten nehmen an der Abstimmung teil.

Ein Knoten fällt aus (2 Knoten verbleiben):

  • Die verbleibenden 2 Knoten bilden eine Mehrheit (66%).
  • Ein neuer Primary wird automatisch gewählt.
  • Das System funktioniert weiterhin für Lese- und Schreibvorgänge.

Zwei Knoten fallen aus (1 Knoten verbleibt):

  • Der verbleibende Knoten kann kein Quorum erreichen (33% < 50%).
  • Das Replica Set wechselt in den schreibgeschützten Modus.
  • Passwork ist für Schreibvorgänge nicht verfügbar.

Schreibgeschützter Modus und Passwork-Verfügbarkeit

Wann der schreibgeschützte Modus eintritt

Ein Replica Set wechselt in den schreibgeschützten Modus, wenn:

  1. Kein Quorum — mehr als die Hälfte der Knoten nicht verfügbar ist.
  2. Netzwerkpartitionierung — Teile des Clusters jeweils weniger als 50% der Knoten haben.

Auswirkung auf Passwork

Wenn sich die Datenbank im schreibgeschützten Modus befindet, ist Passwork vollständig nicht verfügbar. Jede Aktion in Passwork (Anmelden, Daten anzeigen, Einträge erstellen oder aktualisieren) erfordert Schreibvorgänge in der Datenbank, um den Aktivitätsverlauf zu protokollieren. Wenn Schreibvorgänge blockiert sind, können diese Operationen nicht abgeschlossen werden.

Was Benutzer sehen:

  • Verbindungsfehler beim Versuch, die Datenbank zu erreichen
  • Protokollmeldungen wie „read-only mode" oder „no primary available"
  • Fehlermeldungen in der Benutzeroberfläche beim Versuch, das System zu verwenden

MongoDB Replica Set

Architektur

Ein MongoDB Replica Set besteht aus mehreren Knoten, einem Primary und einem oder mehreren Secondary-Knoten.

Knotentypen:

  • Primary — verarbeitet alle Schreib- und Lesevorgänge.
  • Secondary — synchronisiert vom Primary und kann optional Lesevorgänge bedienen.
  • Arbiter (optional) — nimmt an Wahlen teil, speichert aber keine Daten.

Funktionsweise

  1. Schreibvorgänge werden nur auf dem Primary-Knoten durchgeführt.
  2. Oplog (Operation Log) speichert alle Schreibvorgänge.
  3. Synchronisation — Secondary-Knoten lesen das Oplog vom Primary und wenden die Operationen auf ihre Daten an.
  4. Abstimmung — wenn der Primary ausfällt, stimmen die Knoten ab, um einen neuen Primary zu wählen.
  5. Automatisches Failover — ein neuer Primary wird automatisch aus Knoten mit aktuellen Daten gewählt.

Verbindungszeichenfolge

Alle Passwork-Anwendungsserver verbinden sich mit dem Replica Set über eine einzige Verbindungszeichenfolge:

mongodb://node1:27017,node2:27017,node3:27017/pw?replicaSet=rs0

Der MongoDB-Treiber erkennt automatisch:

  • Den aktuellen Primary-Knoten
  • Nach einem Failover leitet er Abfragen an den neuen Primary weiter, der vom Replica Set gewählt wurde

Anforderungen an die Knotenplatzierung

Bedeutung unabhängiger Standorte

Für maximale Ausfallsicherheit verwenden Sie drei unabhängige physische Standorte (Rechenzentren).

Warum das wichtig ist:

  1. Schutz vor Katastrophen — wenn ein Standort ausfällt, laufen die anderen weiter.
  2. Unabhängige Infrastruktur — jeder Standort hat eigene Stromversorgung, Kühlung und Netzwerk.
  3. Geografische Verteilung — Knoten können sich an verschiedenen Standorten befinden.

Empfohlene Platzierungsarchitektur

         ┌─────────────────────────────────────────────────────────────────────┐
│ RECOMMENDED ARCHITECTURE │
│ │
│ ┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐ │
│ │ DC #1 │ │ DC #2 │ │ DC #3 │ │
│ │ │ │ │ │ │ │
│ │ ┌────────────┐ │ │ ┌────────────┐ │ │ ┌────────────┐ │ │
│ │ │ MongoDB │ │ │ │ MongoDB │ │ │ │ MongoDB │ │ │
│ │ │ Node #1 │ │ │ │ Node #2 │ │ │ │ Node #3 │ │ │
│ │ └────────────┘ │ │ └────────────┘ │ │ └────────────┘ │ │
│ │ │ │ │ │ │ │
│ │ Independent │ │ Independent │ │ Independent │ │
│ │ infrastructure │ │ infrastructure │ │ infrastructure │ │
│ └────────┬─────────┘ └────────┬─────────┘ └───────┬──────────┘ │
│ │ │ │ │
│ │ │ │ │
│ └─────────────────────┼────────────────────┘ │
│ │ │
│ High-speed network │
│ (for data replication) │
└─────────────────────────────────────────────────────────────────────┘

Netzwerkanforderungen

Datenbankknoten benötigen:

  • Hochgeschwindigkeitsverbindungen für die Replikation
  • Geringe Latenz für schnelle Synchronisation
  • Stabile Verbindungen mit minimalem Paketverlust
  • Ausreichende Bandbreite für den Replikationsverkehr

Mindestanforderungen

Minimum: 3 Knoten an 3 unabhängigen Standorten

  • Jeder Knoten an einem separaten physischen Standort (Rechenzentrum)
  • Hochgeschwindigkeits-Netzwerkverbindungen zwischen den Standorten
  • Unabhängige Infrastruktur pro Standort

Alternative (nicht empfohlen):

  • 3 Knoten in einem Rechenzentrum, aber auf verschiedenen Servern/Racks
  • Weniger Schutz vor Katastrophen, aber dennoch tolerant gegenüber dem Ausfall eines einzelnen Knotens

Verbindung der Anwendungsserver

Einzige Verbindungszeichenfolge

Alle Passwork-Anwendungsserver verbinden sich über eine Verbindungszeichenfolge.

MongoDB-Treiber erkennen den Primary automatisch, wenn Sie alle Knoten auflisten:

mongodb://db-mongo-1,db-mongo-2,db-mongo-3/?replicaSet=rs0

Automatische Primary-Erkennung

  • Der Treiber erkennt den aktuellen Primary während der Verbindung.
  • Er überwacht die Gesundheit der Knoten.
  • Nach einer Wahl leitet er den Verkehr automatisch an den neuen Primary weiter.

Empfehlungen

  • Verwenden Sie eine gemeinsame Verbindungszeichenfolge auf allen Anwendungsservern.
  • Listen Sie alle Knoten auf, verweisen Sie nicht auf einen einzelnen Host.
  • Setzen Sie angemessene Timeouts für Verbindungen und Operationen.
  • Überwachen Sie das Replica Set, um zu verfolgen, welcher Knoten Primary ist, und Wahlen zu verifizieren.