MySQL Failover-Strategien ohne Datenverlust

1. Warum Failover-Planung mehr ist als ein Notfallknopf

Ein MySQL Failover ist der Prozess, bei dem eine Replica die Rolle der ausgefallenen oder absichtlich abgelösten Primary übernimmt. Viele Teams behandeln Failover als binäres Ereignis, das entweder funktioniert oder nicht, dabei ist die Qualität eines Failovers eine Frage von Grad: Wie viele Transaktionen gehen verloren, wie lange steht die Anwendung still, und wie viele manuelle Schritte sind nötig, bevor der Betrieb wieder normal läuft.

Diese drei Dimensionen, Datenverlust, Ausfallzeit und manueller Aufwand, hängen direkt von der Vorbereitung ab. Ein MySQL Failover, der ohne GTID, ohne semi-synchrone Absicherung und ohne vorherige Tests im Ernstfall zum ersten Mal ausgeführt wird, ist ein Blindflug mit hohem Risiko. Die folgenden Abschnitte zeigen, wie geplanter und ungeplanter Failover systematisch vorbereitet werden, damit im Ernstfall keine Improvisation nötig ist.

2. Geplanter Failover: kontrollierter Rollentausch

Geplanter MySQL Failover findet statt, wenn die aktuelle Primary aus bekannten Gründen abgelöst werden soll, etwa für Wartungsarbeiten, ein Hardware-Upgrade oder einen Rechenzentrums-Umzug. Der entscheidende Vorteil gegenüber ungeplantem Failover: Die alte Primary ist zum Zeitpunkt des Wechsels noch erreichbar und kann kontrolliert in einen sicheren Zustand versetzt werden, bevor die neue Primary Schreibzugriffe übernimmt.

Der korrekte Ablauf beginnt damit, die aktuelle Primary in den Nur-Lese-Modus zu versetzen, sodass keine neuen Schreibvorgänge mehr angenommen werden. Anschließend wartet man, bis die ausgewählte Replica ihren Replikationsrückstand vollständig aufgeholt hat, was sich über den Vergleich der GTID-Sets zuverlässig prüfen lässt. Erst wenn Retrieved_Gtid_Set und Executed_Gtid_Set der Ziel-Replica identisch mit dem Endstand der alten Primary sind, ist ein Wechsel ohne jeglichen Datenverlust garantiert.

-- Planned failover: put the current primary into read-only mode
SET GLOBAL read_only = ON;
SET GLOBAL super_read_only = ON;

-- Wait until the target replica has caught up completely
-- Run on the target replica, using the primary's GTID set as reference
SELECT WAIT_FOR_EXECUTED_GTID_SET('a1b2c3d4-...:1-98421', 30) AS caught_up;
-- Returns 0 once fully caught up, or 1 on timeout

-- On the promoted replica: stop replication and open for writes
STOP REPLICA;
RESET REPLICA ALL;
SET GLOBAL read_only = OFF;
SET GLOBAL super_read_only = OFF;

-- Repoint remaining replicas to the new primary using GTID auto-positioning
CHANGE REPLICATION SOURCE TO
  SOURCE_HOST = 'db-new-primary.internal',
  SOURCE_AUTO_POSITION = 1;
START REPLICA;

3. Ungeplanter Failover: Ausfall ohne Vorwarnung

Ungeplanter MySQL Failover tritt ein, wenn die Primary unerwartet ausfällt, etwa durch Hardware-Defekt, Kernel Panic oder Netzwerkverlust. Hier fehlt die Möglichkeit, die Primary vorher in den Nur-Lese-Modus zu versetzen, und im schlimmsten Fall sind Transaktionen auf der Primary bestätigt, aber noch nicht an eine Replica übertragen worden. Diese Situation ist genau das Szenario, vor dem semi-synchrone Replikation schützt, indem sie Commits erst bestätigt, nachdem mindestens eine Replica den Erhalt der Transaktion quittiert hat.

Bei ungeplantem Failover muss zunächst ermittelt werden, welche Replica den am weitesten fortgeschrittenen GTID-Stand hat, um Datenverlust zu minimieren. Der Vergleich der Executed_Gtid_Set-Werte aller verbleibenden Replicas zeigt, welche Kandidatin am nächsten an der ausgefallenen Primary lag. Diese Replica wird zur neuen Primary befördert, alle anderen Replicas werden anschließend auf sie umgestellt. Manuell unter Zeitdruck durchgeführt, ist dieser Vergleich fehleranfällig, weshalb Tools wie Orchestrator diesen Schritt automatisieren.

-- Run on each remaining replica to compare GTID progress after a primary outage
SELECT @@GLOBAL.gtid_executed AS executed_gtid_set;

-- Determine which replica is missing transactions relative to another
-- An empty result means the first set fully contains the second (more advanced)
SELECT GTID_SUBTRACT(
  'a1b2c3d4-...:1-98421',   -- gtid_executed on replica A
  'a1b2c3d4-...:1-98376'    -- gtid_executed on replica B
) AS missing_on_b;

-- The replica with the most complete GTID set becomes the promotion candidate

4. GTID-basiertes Failover im Detail

GTID ist die technische Grundlage, die MySQL Failover erst zuverlässig automatisierbar macht. Ohne GTID müsste nach einem Failover für jede verbleibende Replica manuell die korrekte Binlog-Position der neuen Primary ermittelt werden, ein fehleranfälliger Prozess, der bei falscher Positionierung entweder Transaktionen doppelt anwendet oder überspringt. Mit aktiviertem GTID genügt CHANGE REPLICATION SOURCE TO SOURCE_AUTO_POSITION = 1, und der Server berechnet die korrekte Startposition selbst anhand des bereits ausgeführten Transaktionssatzes.

Ein Sonderfall bei GTID-basiertem Failover sind sogenannte Errant Transactions: Transaktionen, die auf einer Replica ausgeführt wurden, aber nie auf der ursprünglichen Primary existierten, etwa durch einen versehentlichen Schreibzugriff auf eine vermeintlich schreibgeschützte Replica. Wird eine solche Replica später zur neuen Primary befördert, können andere Replicas beim Versuch, diese Errant Transaction zu replizieren, in einen Fehlerzustand geraten, weil ihr GTID-Set diese Transaktion nicht kennt. Regelmäßige Prüfung mit gtid_purged und striktes Read-Only auf allen Nicht-Primary-Knoten verhindert dieses Problem zuverlässig.

5. Orchestrator: automatisierte Failover-Erkennung

Orchestrator ist ein spezialisiertes Tool zur Topologie-Erkennung und automatisierten Durchführung von MySQL Failover, das kontinuierlich den Zustand aller bekannten MySQL-Instanzen überwacht. Erkennt Orchestrator, dass die Primary über mehrere aufeinanderfolgende Prüfungen nicht erreichbar ist, während gleichzeitig Replicas den Ausfall bestätigen, um Netzwerkprobleme des Orchestrator-Hosts selbst auszuschließen, startet es automatisch den Failover-Prozess und wählt anhand von GTID-Fortschritt, Datenaktualität und konfigurierten Präferenzen die geeignetste Replica als neue Primary aus.

Die Konfiguration erlaubt es, bestimmte Replicas explizit als bevorzugte Failover-Kandidaten oder als von der Beförderung ausgeschlossen zu markieren, etwa Replicas in einer anderen geografischen Region mit höherer Latenz. Orchestrator unterstützt zudem Hooks, die vor und nach einem Failover ausgeführt werden, etwa um DNS-Einträge zu aktualisieren, den MySQL Router neu zu konfigurieren oder ein Alert an das Betriebsteam zu senden. Diese Automatisierung reduziert die Zeit zwischen Ausfall und wiederhergestellter Schreibfähigkeit von potenziell Minuten manueller Arbeit auf wenige Sekunden.

# orchestrator.conf.json (excerpt): key failover-relevant settings
{
  "RecoveryPeriodBlockSeconds": 3600,
  "PreventCrossDataCenterMasterFailover": true,
  "ApplyMySQLPromotionAfterMasterFailover": true,
  "PostMasterFailoverProcesses": [
    "/usr/local/bin/update-dns.sh {failureClusterName} {successorHost}",
    "/usr/local/bin/notify-slack.sh 'Failover completed: {successorHost} is now primary'"
  ]
}

# Manual graceful failover trigger via orchestrator CLI
orchestrator -c graceful-master-takeover \
  -alias production-cluster \
  -d db-replica-2.internal:3306

6. MHA als Alternative für ältere Topologien

MHA, Master High Availability Manager, war lange Zeit das Standardwerkzeug für automatisiertes MySQL Failover, bevor GTID und Orchestrator breite Verbreitung fanden. MHA funktioniert auch mit positionsbasierter Replikation ohne GTID, indem es beim Failover die Differenzen der Binlog-Positionen zwischen Replicas per SSH abgleicht und fehlende Events direkt zwischen den Replicas nachträgt, bevor die neue Primary aktiv wird.

Für neue Setups ist MHA in den meisten Fällen nicht mehr die erste Wahl, weil die Entwicklung weniger aktiv ist als bei Orchestrator und weil GTID-basierte Ansätze robuster und einfacher zu betreiben sind. In bestehenden Umgebungen mit älteren MySQL-Versionen oder ohne GTID-Migration bleibt MHA jedoch eine funktionierende, gut dokumentierte Option, insbesondere wenn ein Team bereits Erfahrung mit dem Tool hat und keine Migration auf GTID kurzfristig geplant ist.

; app1.cnf: MHA application configuration (excerpt)
[server default]
user = mha
password = strong-password-here
ssh_user = root
repl_user = repl
repl_password = strong-password-here
ping_interval = 3

[server1]
hostname = db-primary.internal
candidate_master = 1

[server2]
hostname = db-replica-1.internal
candidate_master = 1

[server3]
hostname = db-replica-2.internal
no_master = 1

; Trigger a manual failover check
; masterha_check_repl --conf=/etc/masterha/app1.cnf
; masterha_master_switch --conf=/etc/masterha/app1.cnf --master_state=dead

7. Datenverlust minimieren: semi-sync als Grundlage

Kein Failover-Tool, egal ob Orchestrator oder MHA, kann Daten wiederherstellen, die nie auf einer Replica angekommen sind. Deshalb ist semi-synchrone Replikation die eigentliche Grundlage dafür, dass MySQL Failover ohne Datenverlust überhaupt möglich ist. Mit aktiviertem rpl_semi_sync_source_enabled und einem angemessen niedrigen Timeout garantiert die Primary, dass jede bestätigte Transaktion bei mindestens einer Replica bereits im Relay Log liegt, bevor der Client eine Erfolgsmeldung erhält.

Für maximale Sicherheit lässt sich mit rpl_semi_sync_source_wait_for_replica_count in neueren MySQL-Versionen konfigurieren, dass mehr als eine Replica bestätigen muss, bevor ein Commit als abgeschlossen gilt. Das erhöht die Sicherheit gegen den gleichzeitigen Ausfall von Primary und der einzigen bestätigenden Replica, geht aber auf Kosten höherer Commit-Latenz. Die Balance zwischen Datensicherheit und Latenz muss pro Anwendung bewusst festgelegt werden, es gibt keine universell richtige Einstellung.

8. Failover sicher testen, ohne die Produktion zu gefährden

Der zuverlässigste Weg, ein MySQL Failover-Setup zu validieren, ist es regelmäßig unter kontrollierten Bedingungen auszuführen, statt zu hoffen, dass es beim ersten echten Ausfall funktioniert. Ein bewährtes Vorgehen ist ein monatlicher oder quartalsweiser geplanter Failover in einer Staging-Umgebung, die produktionsnah aufgebaut ist, inklusive realistischer Schreiblast durch Lastgeneratoren während des Tests.

Für produktionsnahe Tests ohne echten Ausfall eignet sich ein kontrollierter geplanter Failover auf ein weniger kritisches Zeitfenster, etwa außerhalb der Hauptnutzungszeiten, kombiniert mit vollständigem Monitoring der Ausfallzeit und der Anzahl betroffener Requests. Chaos-Engineering-Ansätze, die gezielt Netzwerkverbindungen zur Primary kappen, etwa über iptables-Regeln statt eines echten Server-Absturzes, erlauben es, ungeplanten Failover realistisch zu simulieren, ohne physische Hardware zu beschädigen oder Daten unwiederbringlich zu verlieren.

#!/usr/bin/env bash
# simulate-primary-outage.sh: cut network traffic to the primary for a chaos test
set -euo pipefail

PRIMARY_IP="10.0.0.1"

echo "[CHAOS] Blocking all traffic to/from $PRIMARY_IP"
iptables -A INPUT -s "$PRIMARY_IP" -j DROP
iptables -A OUTPUT -d "$PRIMARY_IP" -j DROP

echo "[CHAOS] Failure injected, watch Orchestrator detect and promote a replica"
sleep 60

echo "[CHAOS] Restoring network access to $PRIMARY_IP"
iptables -D INPUT -s "$PRIMARY_IP" -j DROP
iptables -D OUTPUT -d "$PRIMARY_IP" -j DROP

9. Orchestrator vs. MHA im Vergleich

Beide Tools automatisieren MySQL Failover, unterscheiden sich aber in Architektur, Voraussetzungen und Wartungsaufwand erheblich. Die folgende Tabelle stellt die wichtigsten Unterschiede gegenüber.

Für neue Projekte ist Orchestrator in Kombination mit GTID die klar empfohlene Basis für automatisierten MySQL Failover. MHA bleibt relevant für Legacy-Umgebungen, in denen eine GTID-Migration kurzfristig nicht realistisch ist oder in denen bereits etabliertes Betriebswissen für MHA existiert, das nicht ohne triftigen Grund verworfen werden sollte.

10. Zusammenfassung

Ein robustes MySQL Failover-Konzept ruht auf drei Säulen: semi-synchrone Replikation, um Datenverlust an der Quelle zu verhindern, GTID, um den Wechsel technisch sauber und automatisierbar zu machen, und ein Werkzeug wie Orchestrator, um Erkennung und Ausführung im Ernstfall zu beschleunigen. Geplanter Failover mit vorherigem Nur-Lese-Modus garantiert Nullverlust, ungeplanter Failover minimiert Verlust durch sorgfältige Auswahl der am weitesten fortgeschrittenen Replica.

Der Unterschied zwischen einem Failover-Plan auf dem Papier und einem, der im Ernstfall tatsächlich funktioniert, liegt im regelmäßigen Testen. Chaos-Engineering-Ansätze und geplante Failover-Übungen in Staging-Umgebungen decken Lücken auf, bevor sie in Produktion zum Problem werden. Wer diese Elemente konsequent kombiniert, verwandelt Failover von einer Blackbox in einen planbaren, wiederholbaren operativen Prozess.

11. FAQ: MySQL Failover