Datenbank-Replizierung – Hochverfügbarkeit & Skalierung

Inhaltsverzeichnis

Schnellübersicht

Auf dieser Seite lernen Sie alles über Datenbank-Replizierung:

Definition: Was ist Replizierung und warum wird sie eingesetzt?
Replikationsarten: Master-Slave, Master-Master, Multi-Master
Synchron vs. Asynchron: Konsistenz vs. Performance
Topologien: Stern, Ring, Kette, Baum
Vorteile & Nachteile: Abwägung für verschiedene Use Cases
Implementierungen: MySQL, PostgreSQL, MongoDB, Redis
Best Practices: Monitoring, Konsistenz, Failover
FAQ: Häufige Fragen zur Replizierung

1. Was ist Datenbank-Replizierung?

Definition

Datenbank-Replizierung ist der Prozess, bei dem Daten von einer Datenbank (oder einem Server) auf eine oder mehrere andere Datenbanken kopiert und synchronisiert werden. Das Ziel ist es, mehrere identische oder nahezu identische Kopien der Daten an verschiedenen Orten zu haben.

Replizierung dient hauptsächlich drei Zwecken: Hochverfügbarkeit (bei Ausfall eines Servers übernehmen andere), Skalierung (Leselast verteilen) und Geografische Verteilung (Daten näher an den Benutzern).

Wichtige Begriffe: Master/Primary (Hauptdatenbank, die Schreiboperationen akzeptiert), Slave/Replica (Kopie, die Daten vom Master empfängt), Replikations-Log (Protokoll aller Änderungen), Lag (Verzögerung zwischen Master und Slave).

Replizierung vs. Backup

Replizierung ist kein Ersatz für Backups! Während Backups historische Datenpunkte speichern und vor Datenverlust schützen, bietet Replizierung Echtzeit-Kopien für Hochverfügbarkeit und Skalierung. Beide sollten kombiniert werden.

2. Replikationsarten

Es gibt verschiedene Arten der Replizierung, die sich in der Anzahl der Master und der Richtung der Datenflüsse unterscheiden.

Master-Slave

Ein Master, mehrere Slaves

Der häufigste Replikationstyp. Ein Primary-Server akzeptiert alle Schreiboperationen, mehrere Replica-Server empfangen die Änderungen und können für Leseoperationen genutzt werden.

Ein Master für Schreiboperationen
Mehrere Slaves für Leseoperationen
Einfache Implementierung
Gute Skalierung für Lese-Last
Master ist Single Point of Failure

Typische Anwendung: Web-Anwendungen mit vielen Lese- und wenigen Schreiboperationen (z.B. Blogs, E-Commerce-Kataloge).

Master-Master

Zwei Master, bidirektional

Zwei Server akzeptieren Schreiboperationen und replizieren Änderungen bidirektional. Bietet bessere Ausfallsicherheit als Master-Slave, erfordert aber Konfliktlösung.

Zwei Master für Schreiboperationen
Bidirektionale Replikation
Bessere Ausfallsicherheit
Automatisches Failover möglich
Konfliktlösung erforderlich

Typische Anwendung: Hochverfügbare Systeme mit moderater Schreiblast, wo Ausfallsicherheit kritisch ist.

Multi-Master

Mehrere Master, komplexe Topologie

Drei oder mehr Server akzeptieren Schreiboperationen und replizieren untereinander. Sehr flexibel, aber komplex in der Implementierung und Konfliktlösung.

Mehrere Master für Schreiboperationen
Maximale Ausfallsicherheit
Geografische Verteilung möglich
Hohe Skalierbarkeit
Komplexe Konfliktlösung

Typische Anwendung: Globale Systeme mit Schreiboperationen an mehreren Standorten (z.B. soziale Netzwerke, globale E-Commerce-Plattformen).

Cascade-Replikation

Kaskadenförmige Weitergabe

Ein Master repliziert an einen Slave, dieser wiederum an weitere Slaves. Reduziert die Last auf dem Master, erhöht aber die Latenz für entfernte Slaves.

Entlastet den Master
Skalierbar für viele Slaves
Geringere Netzwerklast auf Master
Geeignet für große Topologien
Höhere Latenz für entfernte Slaves

Typische Anwendung: Große Replikationstopologien mit hunderten von Slaves, wo der Master entlastet werden muss.

3. Synchron vs. Asynchron

Die Wahl zwischen synchroner und asynchroner Replizierung ist eine Abwägung zwischen Konsistenz und Performance.

Synchrone Replizierung

Starke Konsistenz, höhere Latenz

Konsistenz: Daten sind sofort auf allen Servern identisch
Transaktion: Commit erst, wenn alle Slaves bestätigt haben
Datensicherheit: Kein Datenverlust bei Master-Ausfall
Latenz: Höhere Antwortzeiten
Verfügbarkeit: Slave-Ausfall blockiert Master

Empfohlen für: Finanzsysteme, Transaktionssysteme, wo Datenkonsistenz kritisch ist und Latenz sekundär.

Asynchrone Replizierung

Hohe Performance, eventual consistency

Performance: Niedrige Latenz, schnelle Commits
Verfügbarkeit: Slave-Ausfall blockiert Master nicht
Skalierbarkeit: Gut für geografische Verteilung
Konsistenz: Eventual Consistency (Daten nicht sofort synchron)
Datenverlust: Möglicher Verlust bei Master-Ausfall

Empfohlen für: Web-Anwendungen, Content-Systeme, wo Performance wichtiger ist als sofortige Konsistenz.

Semi-Synchrone Replizierung

Ein Kompromiss: Der Master wartet auf Bestätigung von mindestens einem Slave, bevor er commitet. Bietet bessere Konsistenz als asynchron, aber geringere Latenz als voll synchron.

4. Replikations-Topologien

Die Topologie definiert, wie die Server miteinander verbunden sind und wie Daten fließen.

Stern-Topologie

Ein zentraler Master, alle Slaves verbinden sich direkt mit ihm. Einfach zu verwalten, aber Master ist Flaschenhals.

Master → Slave 1
Master → Slave 2
Master → Slave 3

Ring-Topologie

Server sind in einem Ring verbunden, jeder repliziert an den nächsten. Gut für Kaskaden, aber langsamer Propagation.

Server A → Server B
Server B → Server C
Server C → Server A

Ketten-Topologie

Lineare Kette von Servern. Einfach, aber Ausfall eines Servers unterbricht die Kette.

Master → Slave 1 → Slave 2 → Slave 3

Baum-Topologie

Hierarchische Struktur mit mehreren Ebenen. Skalierbar, aber komplexe Verwaltung.

Master → Slave 1 → Slave 1a, 1b
Master → Slave 2 → Slave 2a, 2b

5. Vorteile & Nachteile

Replizierung bietet viele Vorteile, hat aber auch Nachteile, die beachtet werden müssen.

Vorteile

Hochverfügbarkeit: Bei Ausfall eines Servers übernehmen andere
Skalierung: Leselast auf mehrere Server verteilen
Geografische Verteilung: Daten näher an den Benutzern
Redundanz: Mehrere Kopien der Daten
Backup-Entlastung: Backups von Slaves statt Master
Reporting: Analytische Queries auf Slaves ausführen
Disaster Recovery: Schnelle Wiederherstellung

Nachteile

Komplexität: Erhöhte Komplexität in Verwaltung und Monitoring
Konflikte: Bei Multi-Master: Schreibkonflikte möglich
Latenz: Replikations-Lag kann zu inkonsistenten Daten führen
Ressourcen: Erhöhter Speicher-, Netzwerk- und CPU-Verbrauch
Kosten: Mehrere Server = höhere Infrastrukturkosten
Konsistenz: Eventual Consistency kann problematisch sein
Overhead: Replikation erzeugt zusätzlichen Write-Overhead

6. Replikierung in verschiedenen Datenbanken

Jede Datenbank hat ihre eigene Implementierung der Replizierung mit spezifischen Features.

MySQL Replikation

Binlog-basiert, bewährt

Master-Slave: Standard-Modus
Group Replication: Multi-Master (seit 5.7)
Binlog: Row-based oder Statement-based
GTID: Global Transaction IDs
Semi-sync: Semi-synchrone Replikation

PostgreSQL Replikation

Streaming Replication, WAL

Streaming Replication: Echtzeit-Replikation
Logical Replication: Selektive Replikation (seit 10)
WAL: Write-Ahead-Logs
Hot Standby: Slaves können Lese-Queries bedienen
Patroni: HA-Lösung mit automatischem Failover

MongoDB Replica Sets

Automatisches Failover

Replica Sets: Primary + Secondaries
Automatisches Failover: Election-Mechanismus
Oplog: Operation Log für Replikation
Read Preferences: Flexible Lese-Routing
Sharding: Horizontale Skalierung

Redis Replication

In-Memory, ultra-schnell

Master-Replica: Einfache Replikation
Sentinel: Hochverfügbarkeit mit automatischem Failover
Cluster: Sharding + Replikation
Async: Asynchrone Replikation
Partial Resync: Effiziente Re-Synchronisation

Datenbank	Standard-Modus	Multi-Master	Automatisches Failover	Konsistenz
MySQL	Master-Slave	Group Replication	Manuell / MHA	Eventual / Strong
PostgreSQL	Streaming Replication	Logical Replication	Patroni / repmgr	Eventual / Strong
MongoDB	Replica Sets	Sharded Cluster	Automatisch	Eventual / Strong
Redis	Master-Replica	Redis Cluster	Sentinel / Cluster	Eventual

7. Best Practices für Replizierung

Die wichtigsten Empfehlungen für eine stabile und zuverlässige Replikationsumgebung.

Monitoring & Alerting

Replikations-Lag überwachen: Alert bei Lag > X Sekunden
Verbindungsstatus prüfen: Alle Slaves verbunden?
Performance-Metriken: CPU, RAM, I/O auf allen Servern
Logs analysieren: Fehler und Warnungen früh erkennen
Dashboard einrichten: Echtzeit-Übersicht aller Server

Konsistenz sicherstellen

Read-Your-Writes: Nach Schreiboperation auf Master lesen
Session-Sticky:同一 Session immer auf gleichen Server
Consistency Level wählen: Strong vs. Eventual je nach Use Case
Timestamps nutzen: Für Konfliktlösung bei Multi-Master
Vector Clocks: Für komplexe verteilte Systeme

Failover-Strategie

Automatisches Failover: Patroni, Sentinel, MHA einsetzen
Manuelle Prozeduren: Runbooks für manuelles Failover
Regelmäßig testen: Failover-Tests mindestens quartalsweise
RTO/RPO definieren: Recovery Time/Point Objectives festlegen
DNS-Updates: Schnelle DNS-Propagation sicherstellen

Backup-Strategie

Backups von Slaves: Master nicht durch Backups belasten
Point-in-Time Recovery: WAL/Binlog-Archive aufbewahren
3-2-1-Regel: 3 Kopien, 2 Medien, 1 extern
Recovery testen: Regelmäßig Wiederherstellung testen
Verschlüsselung: Backups verschlüsselt speichern

             Wichtige Regeln
            Replizierung ist kein Backup! Immer zusätzliche Backups erstellen.
Monitoring ist essenziell: Ohne Monitoring发现问题 zu spät.
Failover testen: Nur getestete Failover funktionieren im Ernstfall.
Dokumentation pflegen: Topologie, Konfiguration, Prozeduren dokumentieren.
Capacity Planning: Ressourcen für Replikation einplanen.

        

8. FAQ – Häufige Fragen & Antworten

Häufige Fragen zur Datenbank-Replizierung

Was ist der Unterschied zwischen Replizierung und Sharding?

Replizierung: Kopiert die gesamte Datenbank auf mehrere Server. Jeder Server hat alle Daten. Dient der Hochverfügbarkeit und Skalierung von Leseoperationen.

Sharding: Teilt die Datenbank in horizontale Partitionen auf. Jeder Server hat nur einen Teil der Daten. Dient der Skalierung von Schreiboperationen und großen Datenmengen.

Kombination: Oft werden beide Techniken kombiniert: Sharding für Skalierung + Replizierung für Hochverfügbarkeit innerhalb jedes Shards.

Was ist Replikations-Lag und warum ist er problematisch?

Replikations-Lag ist die Verzögerung zwischen einer Schreiboperation auf dem Master und der Anwendung auf den Slaves.

Probleme:

Inkonsistente Daten: Benutzer liest alte Daten vom Slave
Read-Your-Writes-Problem: Benutzer sieht eigene Änderungen nicht sofort
Failover-Risiko: Bei Master-Ausfall können Daten verloren gehen

Lösung: Monitoring, synchrone Replikation für kritische Daten, Read-Your-Writes-Routing.

Wie funktioniert automatisches Failover?

Automatisches Failover erkennt den Ausfall des Masters und befördert automatisch einen Slave zum neuen Master.

Typischer Ablauf:

Health Checks: Monitoring-System prüft regelmäßig Master-Verfügbarkeit
Ausfall erkennen: Nach X fehlgeschlagenen Checks wird Ausfall bestätigt
Slave wählen: Slave mit den meisten Daten wird zum Master befördert
DNS/IP aktualisieren: Clients werden auf neuen Master umgeleitet
Andere Slaves neu konfigurieren: Replizieren nun vom neuen Master

Tools: Patroni (PostgreSQL), MongoDB Replica Sets, Redis Sentinel, MHA (MySQL).

Wann sollte ich synchrone vs. asynchrone Replizierung verwenden?

Synchrone Replizierung verwenden bei:

Finanzsysteme (Transaktionen, Buchhaltung)
Kritische Geschäftsdaten, wo Datenverlust inakzeptabel ist
Compliance-Anforderungen (DSGVO, HIPAA, PCI-DSS)
Kleine geografische Distanz (geringe Latenz)

Asynchrone Replizierung verwenden bei:

Web-Anwendungen mit hoher Lese-Last
Geografisch verteilte Systeme (hohe Latenz)
Content-Systeme, wo leichte Verzögerung akzeptabel ist
Performance-kritische Anwendungen

Wie löse ich Schreibkonflikte bei Multi-Master-Replizierung?

Schreibkonflikte entstehen, wenn zwei Master gleichzeitig dieselben Daten ändern.

Lösungsstrategien:

Last Write Wins (LWW): Änderung mit dem neuesten Timestamp gewinnt
First Write Wins (FWW): Erste Änderung gewinnt, spätere werden verworfen
Vector Clocks: Kausale Abhängigkeiten nachvollziehen
CRDTs: Conflict-Free Replicated Data Types (automatische Konfliktlösung)
Manuelle Auflösung: Konflikte an Anwendung übergeben
Partitionierung: Vermeiden, dass verschiedene Master dieselben Daten ändern

Wie viele Slaves sollte ich haben?

Die Anzahl der Slaves hängt von Ihren Anforderungen ab:

Hochverfügbarkeit: Mindestens 2 Slaves (für Quorum bei Failover)
Leseskalierung: So viele, wie die Lese-Last erfordert
Geografische Verteilung: Einer pro Region
Reporting: Einer für analytische Queries
Backup: Einer für Backups (entlastet Master)

Faustregel: 2-3 Slaves für kleine Systeme, 5-10 für mittlere, 10+ für große Systeme.

Achtung: Mehr Slaves = mehr Replikations-Overhead auf dem Master.

Kann ich Replizierung über das Internet nutzen?

Ja, aber mit Einschränkungen:

Latenz: Hohe Latenz über das Internet (50-200ms vs. <1ms im LAN)
Bandbreite: Replikation erzeugt konstanten Traffic
Sicherheit: Verschlüsselung (TLS/SSL) ist Pflicht
Zuverlässigkeit: Internet-Verbindungen können instabil sein

Empfehlungen:

Asynchrone Replikation: Wegen hoher Latenz
Kompression: Reduziert Bandbreitennutzung
VPN/TLS: Für sichere Verbindung
WAN-Optimierung: Deduplizierung, Caching
Cloud-Anbieter: Managed Replikation nutzen (AWS RDS, Azure SQL)

Was passiert, wenn ein Slave ausfällt?

Bei Master-Slave-Replikation:

Master unaffected: Master arbeitet normal weiter
Andere Slaves unaffected: Andere Slaves replizieren weiter
Reconnect: Slave verbindet sich automatisch beim Neustart
Catch-up: Slave holt verpasste Änderungen nach

Bei Master-Ausfall:

Automatisches Failover: Slave wird zum neuen Master befördert
Manuelles Failover: Admin befördert manuell einen Slave
Downtime: Kurzzeitige Unterbrechung während Failover

Zusammenfassung

             Die wichtigsten Punkte
            Replizierung: Kopiert Daten auf mehrere Server für Hochverfügbarkeit und Skalierung
Master-Slave: Ein Master für Writes, mehrere Slaves für Reads – häufigster Typ
Master-Master: Zwei Master mit bidirektionaler Replikation – bessere Ausfallsicherheit
Multi-Master: Mehrere Master – komplex, aber maximale Flexibilität
Synchron: Starke Konsistenz, höhere Latenz – für kritische Daten
Asynchron: Hohe Performance, eventual consistency – für Web-Apps
Topologien: Stern, Ring, Kette, Baum – je nach Anforderung
Implementierungen: MySQL, PostgreSQL, MongoDB, Redis –各有特点
Best Practices: Monitoring, Konsistenz, Failover-Tests, Backups
Replizierung ≠ Backup: Immer zusätzliche Backups erstellen!

        

             Enterprise-Tipps
            Monitoring einrichten: Replikations-Lag, Verbindungsstatus, Performance überwachen
Failover testen: Regelmäßig Failover-Prozeduren testen
Dokumentation pflegen: Topologie, Konfiguration, Prozeduren dokumentieren
Capacity Planning: Ressourcen für Replikation einplanen
Security: TLS/SSL für Replikations-Verbindungen verwenden
Automation: Tools wie Patroni, Sentinel, MHA für automatisches Failover nutzen

        

Weiterführende Themen

Datenbank-Grundlagen

Grundkonzepte von Datenbanken, SQL, Normalisierung und Datenbankdesign.

Zu Datenbank-Grundlagen

Hochverfügbarkeit

Hochverfügbarkeits-Cluster, Load Balancing und Failover-Strategien.

Zu Hochverfügbarkeit

Backup & Recovery

Backup-Strategien, Recovery-Prozesse und Disaster Recovery.

Zu Backup & Recovery

Datenbank-Optimierung

Performance-Tuning, Indexing, Query-Optimierung und Caching.

Zur Datenbank-Optimierung