Datenbank-Replikation: Daten synchron halten und ausfallsicher machen

Replikation kopiert Daten einer Datenbank kontinuierlich auf einen oder mehrere andere Server. Dadurch entstehen mehrere aktuelle Kopien, die für Lastverteilung, Ausfallsicherheit und Backups genutzt werden können – das ist die Grundlage von Hochverfügbarkeit in fast jedem größeren System.

Grundlegende Architekturen

  • Master-Slave (Primary-Replica): Ein primärer Server nimmt Schreibzugriffe an; ein oder mehrere Replicas übernehmen Lesezugriffe oder dienen als Reserve. Fällt der Master aus, wird ein Replica zum neuen Primary promoviert.
  • Master-Master (Multi-Primary): Mehrere Server akzeptieren Schreibzugriffe und gleichen sich gegenseitig ab. Konfliktlösung ist aufwendig und nur mit geeigneten Werkzeugen empfehlenswert.
  • Cluster mit gemeinsamer Verwaltung: Systeme wie Galera oder MySQL Group Replication synchronisieren Knoten synchron und entscheiden Konflikte automatisch.

Replikationsarten

  • Asynchrone Replikation: Der Primary meldet einen Schreibzugriff sofort als erfolgreich, die Replicas erhalten die Änderung später. Geringe Latenz, aber im Fehlerfall können wenige Änderungen fehlen.
  • Semi-synchrone Replikation: Mindestens ein Replica bestätigt den Empfang, bevor der Primary den Commit abschließt – ein guter Kompromiss.
  • Synchron (Group Replication): Alle Knoten bestätigen, bevor committet wird. Höchste Konsistenz, aber höhere Latenz.

Wofür wird Replikation genutzt?

  • Lastverteilung: Leseanfragen auf Replicas verteilen (Read-Scaling), damit der Primary entlastet wird.
  • Hochverfügbarkeit: Beim Ausfall eines Servers übernimmt ein Replica – Ausfallzeiten sinken deutlich.
  • Backup-Entlastung: Backups vom Replica ziehen, ohne den Produktivserver zu belasten.
  • Migration ohne Ausfallzeit: Das Zielsystem per Replikation nachziehen und dann umschalten (siehe Datenbank-Migration).

Typische Stolpersteine

  • Verzögerung (Lag): Bei hoher Schreiblast hinken Replicas hinterher – Replikationsstatus regelmäßig überwachen (SHOW REPLICA STATUS in MySQL/MariaDB).
  • Fehlerhafte Statements: Ein Fehler auf dem Replica (z. B. doppelter Schlüssel) stoppt den Replikations-Thread und muss manuell behoben werden.
  • Konsistenz: Asynchrone Replikation garantiert letztlich Konsistenz (Eventual Consistency), aber keinen sofort gleichen Stand.
  • Schema-Änderungen: DDL auf dem Primary kann auf Replicas Konflikte auslösen – Schema-Migrationen planen (siehe Views und Trigger).

Verwandte Grundlagen: Transaktionen, ACID, Indizes.